[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] parsing 0x1e+1 as 0x1e +1
From: |
Vincent Lefevre |
Subject: |
Re: [Tinycc-devel] parsing 0x1e+1 as 0x1e +1 |
Date: |
Wed, 27 Apr 2016 13:27:41 +0200 |
User-agent: |
Mutt/1.6.0-6619-vl-r87826 (2016-04-11) |
On 2016-04-27 13:06:14 +0300, Sergey Korshunoff wrote:
> > There should be a space between 0x1e and +1 (see for instance, the
> > output of "gcc -E", "clang -E" and "icc -E")
>
> Space is not required. Check pcc. 0x1e+1 is parsed as 0x1e +1.
So does CompCert 2.4, but IMHO, this is an incorrect interpretation of
the C standard. An error is better than unexpected results due to the
choice done by pcc and CompCert. Here's an example:
#include <stdio.h>
int main(void)
{
int E = 0;
#define E 1
printf ("0x%x 0x%x\n", 0x11-E, 0x1e-E);
return 0;
}
CompCert 2.4 outputs 0x10 0x1e (following its interpretation of 6.4.8)
though if the user expects a subtraction in both cases, he probably
expects that E yields the same value in both cases. But this is not
what one gets (E yields 1 in 0x11-E, but 0 in 0x1e-E).
> If icc/gcc/clang. complain, then this is theire problem. eE is valid
> exp char only for decimal notation. And for hexadeciamal notation it
> is an ordinal digit char.
No, this is not what the C standard says. Transformations are described
in terms of tokentization.
--
Vincent Lefèvre <address@hidden> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)