Bug 56442 - glcpp accepts junk after #else/#elif/#endif tokens
Summary: glcpp accepts junk after #else/#elif/#endif tokens
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: unspecified
Hardware: Other All
: high normal
Assignee: Carl Worth
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-27 00:42 UTC by Matt Turner
Modified: 2012-11-09 22:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


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.


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.