[Mesa-dev] [PATCH 1/2] glcpp: Allow integer expression for #line directive.

[Kenneth Graunke]

On 01/29/2014 02:15 PM, Carl Worth wrote:
> Carl Worth <cworth at cworth.org> writes:
>> Matt Turner <mattst88 at gmail.com> writes:
>>>
>>> LINE_EXPANDED expression expression NEWLINE
>>
>> Yes. Thanks for the catch. I'll expand the testing and follow up with a
>> new set of patches.
> 
> Except that that's totally bogus. We can't parse two adjacent
> expressions with no intervening separator (assuming whitespace is valid
> within each <expression>).

Agreed.  In many cases, it's impossible to know where the first ends and
the second starts.  I suppose you could require both be wrapped in
parenthesis, but...this seems to be a feature of dubious value at best.

> This looks to me like a bug in the GLSL specification. Real
> preprocessors for languages like C do not accept expressions for #line,
> (they do perform macro substitution, but the final result must be an
> integer constant, not an expression). And that's what is in the C
> specifications.

If the C preprocessor disallows this, I am strongly in favor of not
deviating from that.

If GLSL wants to support extra non-trivial preprocessor features, the
spec authors are going to have to start specifying a lot of behavior,
rather than saying "like the C++ preprocessor."  As we discovered when
writing glcpp, there are a /lot/ of fiddly cases in preprocessing; given
the GLSL specification's usual level of rigor, I'm afraid details might
be missed somehow and the two languages would start diverging...and
that's not good for anybody.

Okay, so I've taken this a bit far, but...if cpp doesn't do it, I really
don't think we should.

> A deviation to accept an expression here, (together with the replacement
> of a source-file string, with a source-file number), gives us something
> unparseable, (or at least under-specified).
> 
> It feels like something specified without an implementation in hand,
> (which can lead to problems like this).
> 
> Ian, I asked in the bug[*] already, but I'll ask again here. Where did
> this bug report come from? And can we fix the problem by pushing to have
> the specification updated?
> 
> If not, (that is, if there are real-world users with non-integer-literal
> #line directives), then it would be nice to see what those actually are
> so we could, at the very least, resolve the grammar ambiguity in a
> direction that will solve the real-world cases.
> 
> [*] https://bugs.freedesktop.org/show_bug.cgi?id=72273


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140131/e0c532af/attachment.pgp>