Re: [Tinycc-devel] revert of "Identifiers can start and/or contain"

[Michael Matz]

Hi,

On Mon, 18 Apr 2016, Vladimir Vissoultchev wrote:

> > '#if PATHCMP==stricmp' doesn't do what you want anyway.  The preprocessor
> == can't
> > compare strings, so the above is always true (because no matter if PATHCMP
> is
> > defined to stricmp or not defined it evaluates to zero, and as stricmp is
> no macro
> > it evaluates to zero as well).
>
> Btw, had some time to do a test with this snippet:
>
> #define PATHCMP stricmp
>
> #if PATHCMP==stricmp
>    #error Michael is wrong
> #else
>    #error Michael is right
> #endif
>
> and got these results:
>
> C:> tcc -c test.c
> test.c:4: error: #error Michael is wrong
>
> C:> gcc -c test.c
> test.c:4:6: error: #error Michael is wrong
>     #error Michael is wrong
>      ^

No, Michael is right.  I said "no matter if PATHCMP is defined to stricmp 
(or any other string) or not defined at all, the conditional will always 
evaluate to true".  You proved one side, for the other part:

$ cat x.c
#if PATHCMP==foobar
Michael is right
#endif
$ gcc -E x.c
...
Michael is right
$ gcc -E -DPATHCMP=blaeh x.c
...
Michael is right
$ tcc -E x.c
Michael is right
$ tcc -E -DPATHCMP=blaeh x.c
Michael is right

So, your conditional wasn't actually a conditional at all.

> This surprises me a lot, as I thought it was only VS that was being 
> "clever" and had me tricked here.
>
> Probably this was impl as an extension by some version of gcc onwards or 
> is it part of the standard now?

No.  It's per standard.  An undefined token evaluates to zero in 
preprocessor conditionals.  A token defined to some other token evaluates 
to whatever that token evaluates (in the above, because "blaeh" and 
"foobar" aren't defined, to zero).

Does that clear it up?


Ciao,
Michael.