Matthew Woehlke <mw_triad <at> users.sourceforge.net> writes: > Actually my preference would be binary-search, since it avoids the > "junk" enums and produces the smallest preprocessed input. (And I do > think 200 kb just on figuring out the value for that enum is a bit much; > that's around 4x the size of the pre-cpp source! )
Interesting analysis. > $ echo -e '#define MAX(a,b) (a)>(b)?(a):(b)\nMAX( MAX( MAX (O_APPEND, > MAX (O_BINARY, O_CIO)), MAX (MAX (O_DIRECT, O_DIRECTORY), MAX (O_DSYNC, > O_NOATIME))), MAX (MAX (O_NOCTTY, MAX (O_NOFOLLOW, O_NOLINKS)), MAX (MAX > (O_NONBLOCK, O_SYNC), MAX (O_TEXT, 0))))' | gcc -E - | wc -c > 2395 Why not go with something even more compact? After all, the idea here is to find the next unused bit, and we already know that all the existing values are bitwise distinct or 0. No need to use MAX when we can rely on bit-twiddling. echo -e '#define O_FULLBLOCK_TMP ((O_APPEND | O_BINARY | O_CIO | O_DIRECT | O_DIRECTORY | O_DSYNC | O_NOATIME | O_NOCTTY | O_NOFOLLOW | O_NOLINKS | O_NONBLOCK | O_SYNC | O_TEXT) << 1)\n(O_FULLBLOCK_TMP & (O_FULLBLOCK_TMP - 1))' | gcc -E - | wc -c 379 -- Eric Blake _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
