On Mon, 2010-12-06 at 17:10 -0800, Carl Worth wrote: > On Mon, 06 Dec 2010 20:23:52 +0000, José Fonseca <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev