Collin Funk wrote: > I worry though that in some cases programs will be accustomed to > glibc's behavior. Since all of the functions are just macros to static > inline functions in <bits/byteswap.h> arguments will only be evaluated > once. It seems like it could be the cause of some unexpected bugs...
The simple fix to your worry is: Let the user use '-Wall' routinely. gcc has a warning option '-Wsequence-point', included in '-Wall'. clang has a warning option '-Wunsequenced', included in '-Wall'. The do the job, and I have not seen them produce false warnings ever. $ gcc -Wall foo.c foo.c: In function ‘main’: foo.c:15:59: warning: operation on ‘value_macro’ may be undefined [-Wsequence-point] 15 | printf ("2. %#" PRIX32 "\n", bswap_32_macro (value_macro++)); | ^ foo.c:7:31: note: in definition of macro ‘bswap_32_macro’ 7 | (((x) & 0x00FF0000) >> 8) | \ | ^ foo.c:15:59: warning: operation on ‘value_macro’ may be undefined [-Wsequence-point] 15 | printf ("2. %#" PRIX32 "\n", bswap_32_macro (value_macro++)); | ^ foo.c:7:31: note: in definition of macro ‘bswap_32_macro’ 7 | (((x) & 0x00FF0000) >> 8) | \ | ^ foo.c:15:59: warning: operation on ‘value_macro’ may be undefined [-Wsequence-point] 15 | printf ("2. %#" PRIX32 "\n", bswap_32_macro (value_macro++)); | ^ foo.c:7:31: note: in definition of macro ‘bswap_32_macro’ 7 | (((x) & 0x00FF0000) >> 8) | \ | ^ $ clang -Wall foo.c foo.c:15:59: warning: multiple unsequenced modifications to 'value_macro' [-Wunsequenced] 15 | printf ("2. %#" PRIX32 "\n", bswap_32_macro (value_macro++)); | ^~ foo.c:5:31: note: expanded from macro 'bswap_32_macro' 5 | #define bswap_32_macro(x) ((((x) & 0x000000FF) << 24) | \ | ^ 6 | (((x) & 0x0000FF00) << 8) | \ | ~ 1 warning generated. Assume this warning option is used. Then you can leave byteswap.h as it is. Bruno