With a function, type checking and type conversion is performed upon entry.
Of course you can perform type conversion in a macro, but type checking?
> (2) Your desired usage would require a non-inlined instance of the
> "inline" function to point to.
Yes, but only then. All instances not requiring a address to htonl will
be inlined.
> (3) Why on earth do you want the address of ntohl? It's not like
> you need to change endianness at runtime...
No, but maybe the choice of converting or not converting. Imagine a
function making a data structure for host or network use. When asked for
a host order data structure, a parameter can be passed to the function
that does that conversion (nothing), and when a network order structure
is wanted, htonl can be passed.
This is just an example I just made up, but why should the kernel's
include files tell people what to code?
> This code is a toy example of using a function pointer, yet tells us
> nothing about *why* you want to do so...and I really think you don't.
> What context are you working in, and what other function(s) might you
> point to besides htonl?
This is not a thing I'm working on, I just found out the inconsistency
between little endian and big endian implementations of ntohl and the
other functions.
Imagine a programmer working on an Intel or Alpha platform. He codes the
function I suggested above, and everything works, since ntohl is a
function. Then, someone tries to compile his code on a Sparc. This
doesn't work very well, since ntohl is a macro.
> See (4) above. Note that the function ought not to be declared static
> if there's any possibility of multiple places forcing the compiler to
> make an out-of-line copy of the htonl function...(prototype in the
> header, actual definition in one place only)
If the function is not declared static, it will be exported, and since
many .c files will certainly include this .h file, multiple definitions
will give error messages at link time.
Well, why bother, when you can make ugly solutions and get away with it?
/Magnus
map@stacken.kth.se