Optional hexadecimal-string support -- 1.8.0 inconsistent now!

[Michel Hack <hack@xxxxxxxxxxxxxx>]

I'm sorry to say that the "should" in 5.12.3 had escaped my attention, as
there are in fact TWO "shall"s, in 5.4.3 and again in the 5.12 preamble.

Actually, I take that back.  Draft 1.7.0 was entirely consistent on the
topic:  implementations (aspiring to 754(2008) conformance SHALL support
the conversions, and *language standards* SHOULD support them.  That's
pretty clear to me.  We cannot really issue a SHALL to another standard,
that's just impolite.

So the text of 5.12.3 looked fine with "should", and I clearly understood
that support was in fact mandatory for conformance.

What ALSO escaped my attention (until now) was that draft 1.8.0 still has
"shall" in that 5.12 preamble (page 37 line 20), so draft 1.8.0 now has a
genuine conflict between 5.4.3 and 5.12, where 1.7.0 was consistent.


So perhaps the "resolution" was a mistake, as there was nothing to
resolve -- unless there were strong recent comments complaining about
the impact of requiring this support.  Was that really the case?


The issue illustrates the interplay between changes in different areas.

There is sometimes a need to initialise binary floating-point constants
to precisely-defined values.  For example, some algorithms require a
representation of ln(2.0) as a sum of two doubles where the first one
has a certain known number of trailing zeros in its significand.  These
cases tend to be difficult to deal with in supposedly-portable code.

When conversion from decimal strings was not always required to round
correctly (and many implementations did not), something had to give.
One could not rely on carefully-constructed decimal constants to result
in the desired binary bit pattern -- and this was I believe the strongest
motivator for hexadecimal strings.  Non-portable programs could of course
use type overlays to deposit any bit pattern -- it's the desire for a
portable solution that drove this.  When support is optional, protability
suffers.

With correctly-rounding decimal string support and a small number of
fixed formats, the problem became less urgent.  Was that one of the
motivations to drop the requirement?

Trouble is, we recently added all those extended and extendable formats,
making the route through decimal strings rather arduous, as I mentioned
earlier.

One can of course always compute those values at run time from integers
and applications of the scaleB operation, so I don't think the loss is
catastrophic.  My only question is, was it intentional and well reasoned?

Michel.
Sent: 2008-04-09 15:27:21 UTC