Path: utzoo!attcan!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.std.c
Subject: Re: 0x47e+barney not considered C
Message-ID: <11445@steinmetz.ge.com>
Date: 1 Jul 88 15:34:52 GMT
References: <120200001@hcx2> <10413@ulysses.homer.nj.att.com>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 26

In article <10413@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes:

| I believe an explicit syntax for pp-numbers is required.  The "0xe+b"
| example points to a flaw in the current definition. But, in my
| opinion, it is a minor flaw and does not require a change at this
| stage in the standardization process.

  I hate to say this, but a bad standard which breaks existing programs
should not be rushed out the door, even if everyone is tired of working
or waiting on it. If it breaks existing programs, there better be a
better rationale than the convenience of the compiler implementors. If
this really was the intent that hex number ending in e can't be followed
by a variable, then I don't see any rationale at all. If the wording is
poor it should be changed.

  Was it intended that exponentiol value be allowed on hex (and I assume
octal) values? If so, how about fractional values, such as "0x1ea.b", or
even worse "0x1ea.e+2"? Is the final e a fractional part or an exponent?

  I will assume that the committee intended this to work as it always
has, and not have a program which will fail if there is no whitespace
somewhere. This should just be an editorial change.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me