[Mesa-dev] [GLSL] defined expressions

José Fonseca jfonseca at vmware.com
Tue Dec 7 10:06:07 PST 2010


On Mon, 2010-12-06 at 17:10 -0800, Carl Worth wrote:
> On Mon, 06 Dec 2010 20:23:52 +0000, José Fonseca <jfonseca at vmware.com> wrote:
> > I suppose it is possible for space to be significant on a conditional
> > expression, e.g.,
> > 
> >   #if foo ()
> > 
> > vs 
> > 
> >   #if foo
> 
> There's no significant whitespace here. A function-like macro can be
> invoked without or without intervening whitespace between the macro name
> and the '(' character. (It's only when *defining* the macro that the
> space is significant.)
> 
> Meanwhile, a single macro "foo" cannot exist as both a function-like and
> an object-like macro at the same time.
> 
> > If there isn't an obvious cleaner solution, would you mind I commit my
> > original patch:
> ...
> >         +|      DEFINED SPACE IDENTIFIER {
> >         +               int v = hash_table_find (parser->defines, $3) ? 1 : 0;
> >         +               $$ = _token_create_ival (parser, INTEGER, v);
> >         +       }
> >          |      DEFINED '(' IDENTIFIER ')' {
> >                         int v = hash_table_find (parser->defines, $3) ? 1 : 0;
> >                         $$ = _token_create_ival (parser, INTEGER, v);
> 
> This is at least inadequate in that it doesn't also add the case for:
> 
> 	DEFINED SPACE '(' IDENTIFIER ')'

Good point.

> But a much cleaner solution would be to simply change the
> conditional_tokens production to not have "space_tokens = 1". Ken and I
> discussed this over lunch today and he agreed to do that.
>
> > It doesn't makes things any worse, and it would allow us to focus on
> > other problems.
> 
> Yes, getting this fixed and moving on will be great. :-)

Sounds great! Thanks

Jose



More information about the mesa-dev mailing list