Hexidecimal floating-point constants <9212291733.AA07745acurley.osf.org>

[queueing-rmail]

With regard to my suggestion that the NCEG might consider providing some
"standard" way to write NaNs & Infinities, Michael Meissner writes:
  
  Given that there are still systems out there which are not IEEE
  754/854 complaint, how would you propose an alternative format which
  handles all of the different formats of NaNs, the two infinities
  (+/-), and subnormal numbers?  If you mean to encode the floating
  point number directly as bits, then this isn't very portable.

I think what Mike is doing here is imagining what sort of notation I might
proposed for the expression of such things as NaNs, and then rightly noting
that whatever notation I might propose would permit (but not require)
programmers to write non-portable code.

To put this in the proper light, I don't think that any given notation by
which one could encode NaNs would (in and of itself) force anyone into
writing non-portability code.  I agree that if you give people the *ability*
to write NaNs, then some programmer is going to avail himself of that, and
he'll write a NaN into some C source code file (thus making that code non-
portable).  But the problem here is not the *notation* used... it is the
fact that the programmer wrote a NaN, together with the fact that some
machines simply do not support NaNs.  The NaN itself is non-portable,
independent of the lexicon used to write it.

So it really isn't a question of whether the notation used for such things
is non-portable.  Rather, the question is "Can the notation be used to
encode non-portable values?"  The answer to this question must clearly be
"yes", but I see no problem with that.  The ANSI C rationale lists as one
of its "guiding principals" that "C code can be non-portable".  This has
always been true and it always will be true.  Just making it difficult for
programmers to obtain the values they need will not make it particularly
less true.

Note that within the current definition of ANSI C, it is difficult, but
certainly not impossible, to obtain a NaN.  For example, if forced to do
so, I (and other programmers) will write:

		float yield_single_nan ()
		{
			union { float f; unsigned u; } tricky_union;

			tricky_union.u = 0x7fc00000;
			return tricky_union.f;
		}

Now neither I nor anyone else interested in portable programming would en-
courage such coding, but if you gotta use it then you gotta use it... and
real programmers *do* use such techniques, even though they are blatantly
non-portable.  Just telling people not to do this sort of think will not
stop it from happening, nor should it necessarily.  Just as the ANSI C
rationale notes, C should be a language in which immediate and platform-
specific needs should be supported IN ADDITION TO providing ways to write
truly portable code.

So given that people are already allowed to write code like that shown
above, the only real question is "Can NCEG provide or suggest a more
convenient notation for achieving essentially the same thing (perhaps
even in a compile-time constant expression)?"

I think the answer is yes, and I think there is a simple way to do just
that via some relatively minor loosening of the existing ANSI C semantic
rules.  In particular, I'm thinking of the following two minor changes
to the current ANSI C rules:

	o	Define numeric literals to be non-modifiable lvalues rather
		than rvalues.

	o	Permit casts within arithmetic constant expressions to
		convert values of "pointer-to-arithmetic" types to different
		"pointer-to-arithmetic" types (even outside of `sizeof'
		expressions).

These minor backward-compatible modifications to the existing ANSI C semantic
rules would permit (for example):

		#define SINGLE_QNAN (*(float*) &0x7fc00000)

		float my_qnan = SINGLE_QNAN;

This is admitedly non-portable, but it is still preferable (in my opinion)
to forcing people to use the union hack shown above (which is also highly
non-portable by the way).


// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
// 	"On the one hand I knew that programs could have a compelling
// 	 and deep logical beauty, on the other hand I was forced to
// 	 admit that most programs are presented in a way fit for
// 	 mechanical execution, but even if of any beauty at all,
// 	 totally unfit for human appreciation."
// 						-- Edsger W. Dijkstra