diff options
author | Carl Worth <[email protected]> | 2014-06-12 14:56:47 -0700 |
---|---|---|
committer | Carl Worth <[email protected]> | 2014-07-09 12:05:13 -0700 |
commit | 9794f8f2452b796740a30abf6d6454452ff3f028 (patch) | |
tree | 3f518452b690049e1a705d26df33856879a617e7 /src/mapi/mapi_glapi.c | |
parent | 98c0e3c7834f8a99f7641aa14b2bab5221aa66db (diff) |
glsl/glcpp: Fix glcpp to properly lex entire "preprocessing numbers"
The preprocessor defines a notions of a "preprocessing number" that
starts with either a digit or a decimal point, and continues with zero
or more of digits, decimal points, identifier characters, or the sign
symbols, ('-' and '+').
Prior to this change, preprocessing numbers were lexed as some
combination of OTHER and IDENTIFIER tokens. This had the problem of
causing undesired macro expansion in some cases.
We add tests to ensure that the undesired macro expansion does not
happen in cases such as:
#define e +1
#define xyz -2
int n = 1e;
int p = 1xyz;
In either case these macro definitions have no effect after this
change, so that the numeric literals, (whether valid or not), will be
passed on as-is from the preprocessor to the compiler proper.
This fixes the following Khronos GLES3 CTS tests:
preprocessor.basic.correct_phases_vertex
preprocessor.basic.correct_phases_fragment
v2. Thanks to Anuj Phogat for improving the original regular expression,
(which accepted a '+' or '-', where these are only allowed after one of
[eEpP]. I also expanded the test to exercise this.
v3. Also fixed regular expression to require at least one digit at the
beginning (after an optional period). Otherwise, a string such as ".xyz" was
getting sucked up as a preprocessing number, (where obviously this should be a
field access). Again, I expanded the test to exercise this.
Reviewed-by: Anuj Phogat <[email protected]>
Diffstat (limited to 'src/mapi/mapi_glapi.c')
0 files changed, 0 insertions, 0 deletions