Bug in gcc parser

Started by 42Bastian Schick July 14, 2005
FYI,

a co-worker found a bug in gcc parser (all gcc's I could get hands on):
Following bails out (but compiles correctly on all other compilers I could
get hands on):

int a = 0x3e+2;

gcc seems to take it as scientific notation.

Regards,

--
42Bastian Schick



An Engineer's Guide to the LPC2100 Series

It's interesting how I just came across this in a GCC compiler manual
yesterday...
This is considered hexadecimal floating point by the compiler. Just put
spaces around the "+" and it should work OK.

Jim

On 7/14/05, 42Bastian Schick <bastian42@bast...> wrote:
>
> FYI,
>
> a co-worker found a bug in gcc parser (all gcc's I could get hands on):
> Following bails out (but compiles correctly on all other compilers I could
> get hands on):
>
> int a = 0x3e+2;
>
> gcc seems to take it as scientific notation.
>
> Regards,
>
> --
> 42Bastian Schick




Jim

> It's interesting how I just came across this in a GCC compiler manual
> yesterday...

I read the manual now, but still I think 0x3e+2 must be compiled and give
0x40.

> This is considered hexadecimal floating point by the compiler. Just put
> spaces around the "+" and it should work OK.

Yes. It is, but it meant touching code :(

--
42Bastian Schick



On Fri, Jul 15, 2005 at 07:59:06AM +0200, 42Bastian Schick wrote:
> I read the manual now, but still I think 0x3e+2 must be compiled and give
> 0x40.

I disagree with the GCC implementers on this, but nonetheless a strict
interpretation of the ANSI/ISO standard for C does mean that 0x3e+2 is
parsed as an invalid floating point number. My view is that a more intelligent
interpretation would be preferable, but that's not what GCC does. --
Clyde Stubbs | HI-TECH Software
Email: clyde@clyd... | Phone Fax
WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885
PGP: finger clyde@clyd... | AUS: +61 7 3552 7777 +61 7 3552 7778
---
HI-TECH C: compiling the real world.



Clyde,

> On Fri, Jul 15, 2005 at 07:59:06AM +0200, 42Bastian Schick wrote:
> > I read the manual now, but still I think 0x3e+2 must be
> compiled and
> > give 0x40.
>
> I disagree with the GCC implementers on this, but nonetheless
> a strict interpretation of the ANSI/ISO standard for C does
> mean that 0x3e+2 is parsed as an invalid floating point
> number. My view is that a more intelligent interpretation
> would be preferable, but that's not what GCC does.

Even under C90, 0x3e+2 is a good preprocessing number but a bad C
floating point literal and *must* be reported as an error!

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors