🚀 go-pugleaf

(on `0x2e+0')

In article <9611210213.AA09203@vlsi1.ultra.nyu.edu>,
Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>*You* may be interpreting it as three tokens, and that's how a C
>compiler would have interpreted it (and how GCC will with
>-traditional), but that's *not* the way an ANSI C compiler is required
>to interpret it.

Richard Kenner is right.  The relevant sections of the ANSI standard
(to get ISO sections, add 3 to the first number, and if the result
seems wrong, look forward and back a bit just in case) are:

	2.1.1.2, Translation Phases
		(pay particular attention to phases 3 and 7)
	3.1, Lexical Elements
	3.1.8, Preprocessing Numbers

When 0x2e+0 is converted from a pp-token to a token, it violates
the `shall' in the constraint in section 3.1 (p. 19, ll 28--29);
a diagnostic is required.

A compiler that fails to emit any diagnostic for a program that
includes the pp-number `0x2e+0' where a number is required fails
to conform to the Standard.

The syntax for a pp-number is remarkably inclusive:

	pp-number:
		digit
		. digit
		pp-number digit
		pp-number nondigit
		pp-number e sign
		pp-number E sign
		pp-number .

Thus, 0_e+1r7E-alphabet_soup_42 is a single `pp-number'.  An X3J11
committee member (I forget which one) told me in 1987 or 1988 or
so that this was intentional; in particular, it allows future C
standards to add new numeric notations.  For instance, if someone
were particularly hot for binary:

	0b101

could be added as a new way to specify the number `5'.
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167