Bug 56442 - glcpp accepts junk after #else/#elif/#endif tokens
glcpp accepts junk after #else/#elif/#endif tokens
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: glsl-compiler
unspecified
Other All
: high normal
Assigned To: Carl Worth
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-27 00:42 UTC by Matt Turner
Modified: 2012-11-09 22:36 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Turner 2012-10-27 00:42:16 UTC
The following preprocessor blocks are incorrectly accepted by glcpp.

#if 0
#else garbage
#endif

#if 1
#else
#endif garbage

#if 1
#elif garbage
#endif

#if 0
#endif garbage

#ifdef FOO
#endif garbage

#define BAR
#ifndef BAR
#endif garbage

Inverting the if/ifdef/ifndef conditionals causes appropriate errors to be generated for the trailing garbage.

None of the glcpp tests in Mesa or piglit exercise trailing junk after #else/#elif/#endif tokens.

A test in gles3's conformance suite (preprocessor17_frag) tests this (it's actually part of gles2's suite I think though).
Comment 1 Ian Romanick 2012-10-29 17:08:20 UTC
I don't see that test in the ES2 suite.

How do similar tests function on other desktop implementations?  I think Eric mentiond on IRC that there is a lot of variation among various preprocessor implmentations.  Because of this a lot of apps accidentially depend on out-of-spec behavior.  This particalur one is a hold over from pre-ANSI C:

#ifdef FOO
/* lots of code */
...
#endif FOO

Depending on how other implementations behave, we may have to maintain our current behavior for desktop GL.
Comment 2 Matt Turner 2012-10-29 17:23:55 UTC
(In reply to comment #1)
> I don't see that test in the ES2 suite.

It may just be in the ES3 suite.

> How do similar tests function on other desktop implementations?  I think
> Eric mentiond on IRC that there is a lot of variation among various
> preprocessor implmentations.  Because of this a lot of apps accidentially
> depend on out-of-spec behavior.  This particalur one is a hold over from
> pre-ANSI C:
> 
> #ifdef FOO
> /* lots of code */
> ...
> #endif FOO
> 
> Depending on how other implementations behave, we may have to maintain our
> current behavior for desktop GL.

Here's the thing -- simply from that example you can't say what our glcpp would do. If FOO is defined, the example will fail to parse. If FOO is not defined, it'll be accepted. I can't see any reasoning for that except that it's an artifact of glcpp's token skipping code.