aboutsummaryrefslogtreecommitdiffstats
path: root/src/glsl/glcpp/tests/124-preprocessing-numbers.c
diff options
context:
space:
mode:
authorCarl Worth <[email protected]>2014-07-03 14:16:07 -0700
committerIan Romanick <[email protected]>2014-08-07 16:08:29 -0700
commit41540997fbc74a6f67fe4e4e6990f2f3119c0201 (patch)
tree5b99799888dcd14c96bceef3b5fbcdf1b6588147 /src/glsl/glcpp/tests/124-preprocessing-numbers.c
parent318369acebdf6e7c21c0a2b015c648e8e9acbc81 (diff)
glsl/glcpp: Fix handling of commas that result from macro expansion
Here is some additional stress testing of nested macros where the expansion of macros involves commas, (and whether those commas are interpreted as argument separators or not in subsequent function-like macro calls). Credit to the GCC documentation that directed my attention toward this issue: https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Argument-Prescan.html Fixing the bug required only removing code from glcpp. When first testing the details of expansions involving commas, I had come to the mistaken conclusion that an expanded comma should never be treated as an argument separator, (so had introduced the rather ugly COMMA_FINAL token to represent this). In fact, an expanded comma should be treated as a separator, (as tested here), and this treatment can be avoided by judicious use of parentheses (as also tested here). With this simple removal of the COMMA_FINAL token, the behavior of glcpp matches that of gcc's preprocessor for all of these hairy cases. Reviewed-by: Ian Romanick <[email protected]>
Diffstat (limited to 'src/glsl/glcpp/tests/124-preprocessing-numbers.c')
0 files changed, 0 insertions, 0 deletions