🚀 go-pugleaf

In article <15217@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
| (For those readers who don't know why "0x7e-getchar" is a single pp-token: The
| Committee defined a single pattern to cover all variants of numeric constants,
| including floating-point with exponents as well as hex integers.  They chose
| to accept the resulting wart (that hex constants ending with "e" must not be
| immediately followed by a sign) rather than rewrite the pattern to fix it.
| Yes, I think this was a mistake.  No, it can't be changed.)

  Correct on all three. That is the way the standard works, it is a
mistake, and it can't be changed.

  I *don't* believe that there is a body of existing programs using hex
constants with exponential notation, and I *do* believe that it breaks
existing programs. I think the committee got tired of the job and
decided that it was good enough. I admit I only found one program it
actually broke, although I did find about 30 instances of #defined hex
constants ending in e which *could* break if used with +/-.

Example, for those not following this:

	#define F_LIMIT	0x14e

	/* and later in the program */
	long error_count[F_LIMIT+5];	/* room for quadrant totals */

	/* and also */
	top3 = triad(bset, F_LIMIT+3);

  The last is interesting, because if F_LIMIT+3 is taken as a float
value, and if there is a prototype, the number gets converted back to an
int. This gives the arg the correct type but a vastly wrong value.

  I'm happy to say that for the moment I haven't seen any compilers
implement this, even those which have many other ANSI features. I'm
really hoping that this could be treated as a wording change, not
requiring a vote, but I suspect it is too big for that.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon