[Mesa-dev] glcpp's handling of #elif with no expression

Carl Worth cworth at cworth.org
Tue Nov 27 17:35:47 PST 2012


Matt Turner <mattst88 at gmail.com> writes:
> Here's the write-up of what I was seeing earlier today for my own record.
>
> #if 1
> #elif
> #endif
>
> gives "0:2(1): preprocessor warning: ignoring illegal #elif without
> expression". gcc rejects it, but glcpp just warns since #if is true
> and it doesn't need to evaluate #elif's nonexistent expression.

Ah, OK. This is the case I wasn't thinking through clearly when we
looked at the code. But that makes sense now, and jibes with what I
recall doing. Are you OK with a warning in this case? Or would you
prefer it to be silent?

> Switching #if 1 to #if 0 correctly gives "0:2(1): preprocessor error:
> #elif with no expression".

Good. That one looked correct from the code.

> Due to how skipping works, we have to pass the #elif tokens to the
> parser, leading to situations like:
>
> #if 0
> # if 1
> # elif
> # endif
> #endif
>
> which still gives the warning message.

Right. And this is the kind of thing (a big "#if 0" eliminating a bunch
of junk) I was thinking about yesterday. It seems like it would be nice
to allow any kind of junk within a "#if 0" block and have it all just
silently ignored, (since the programmer is intentionally hiding all of
this from the compiler).

But of course, it's not that simple, since the compiler does have to
look to find the correct, matching #endif statement. So the compiler is
well within reason to insist that things like #elif are well formed.

Given all of the above, I'd be inclined to leave the warning in
place. What do you think?

It is a bit funny that gcc raises an error in that first case and is
silent in this last one. Would it be worth it to try to match that
behavior?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20121127/85cc0aa5/attachment.pgp>


More information about the mesa-dev mailing list