Sun 24 May 2009 10:16:31 PM UTC, comment #3:
hanhui's comment #1 refers to the issue that a macro parameter with side effects (such as pre-increment or post-increment) will cause the side effect to occur multiple times if the parameter is referenced more than once in the macro.
In this case, assuming htons() is defined like this:
#define htons(x) LWIP_PLATFORM_HTONS(x)
#define LWIP_PLATFORM_HTONS(x) (u16_t)((((x) & 00ff) << 8) | \
(((x) & 0xff00) >> 8))
then the expression htons(++ping_seq_num) will expand to
(u16_t)((((++ping_seq_num) & 00ff) << 8) | \
(((++ping_seq_num) & 0xff00) >> 8))
As you can see, ping_seq_num is incremented twice.
This use of pre-increment or post-increment operators within the parameters to htons() is only valid if htons() is required to be a function. If it is ever implemented as a macro, the expression will have unexpected side effects.
The question then is whether htons() etc. are supposed to be functions. If this is a documented requirement, then this ping code is correct. If the port is allowed to implement htons() as a macro, then this ping code is wrong, and there may be other instances in the LWIP code where the same assumption is made.
|