Jim Meyering wrote:
How about this instead?
D'oh, collision with the other mail I was writing. Yes, that would be
fine, or you can avoid the extra values all together by shifting
parentheses to make it a binary search instead of linear.
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! :-) )
In case you're curious how I came up with that number (aside increasing
-H until it compiled), you can verify yourself:
$ echo -e '#define MAX(a,b) (a)>(b)?(a):(b)\nMAX (O_APPEND, MAX
(O_BINARY, MAX (O_CIO, MAX (O_DIRECT, MAX (O_DIRECTORY, MAX (O_DSYNC,
MAX (O_NOATIME, MAX (O_NOCTTY, MAX (O_NOFOLLOW, MAX (O_NOLINKS, MAX
(O_NONBLOCK, MAX (O_SYNC, MAX (O_TEXT, 0))))))))))))))' | gcc -E - | wc -c
211122
$ 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
(So obviously I am using a slightly larger expansion of MAX, but the
growth principles will be the same.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Two IIRC's must make a right" -- Larry Hall (paraphrased)
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
