Bug 56442

Summary: glcpp accepts junk after #else/#elif/#endif tokens
Product: Mesa Reporter: Matt Turner <mattst88>
Component: glsl-compilerAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: idr
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.