From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <177026a0aecda1f362ae29664a0bcaf8@coraid.com>
From: erik quanstrom <quanstro@coraid.com>
Date: Sun, 18 Feb 2007 16:22:05 -0500
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cc lexer bug?
In-Reply-To: <cd10e193dd8f20c43d30c91b7a8dd4a5@plan9.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 115798f6-ead2-11e9-9d60-3106f5b1d025

you're right, that's wrong.  but the question is do
you really want that to work?

in that case, one could always remove the goto ncu
on line 757.

however, for better or worse, octal constants start with a 0.
08.7 feels like a syntax error to me.  i am a little
suprised that gcc accepts 08.7.  are you sure that that's
actually in the standard?

this testcase should do:

double d =3D 08.7;

- erik
On Sun Feb 18 15:26:26 EST 2007, JoelCSalomon@Gmail.com wrote:
> cpu% cat t.c
> void foo (void)
> {
> 	double d;
> 	d =3D 08.7;
> 	USED(d);
> }
> cpu% 8c t.c
> t.c:4 syntax error, last name: 8.7
> cpu%=20
>=20
> This came up as I=E2=80=99m making my lexer for C able to scan numbers.=
  I
> tried to understand ken=E2=80=99s code, but it gets very hairy right ar=
ound
> /sys/src/cmd/cc/lex.c:751 =E2=80=94 and I think there=E2=80=99s a bug. =
 Or, at least,
> an undocumented departure from the ANSI standard; Harbison & Steele
> (5E) suggest that =E2=80=9C08.7=E2=80=9D is a valid floating point cons=
tant.
>=20
> As far as my lexer is concerned (http://www.tip9ug.jp/who/chesky/comp/l=
ex.c,
> if anyone cares), it=E2=80=99s using line-at-a-time buffering courtesy =
of
> Brdstr(2), so I=E2=80=99m back to thinking that regcomp(2) + strtod(2) =
et al.
> is the way to go.  It won=E2=80=99t handle hex floats, but who cares?
>=20
> --Joel