🚀 go-pugleaf

I (Mark Brader, msb@sq.com) wrote:
 
> > There is a little bit of looseness in the standard in that it doesn't
> > say that the implementation-defined conversions must always yield the
> > same result for the same value.  As far as I know, this has not been
> > the subject of an official ruling, but it seems clear to me that the
> > intent is that it should -- the consequences otherwise would be
> > ridiculous.

I was talking about conversions involving integral types, but Paul Eggert
(eggert@twinsun.com)'s observation:

> But what about the common practice of giving programmers run-time (or
> compile-time) control over the IEEE floating point rounding mode?
> Doesn't that cause implementation-defined conversions to yield
> different results for the same value?

is still relevant since the essence of the matter may be considered to be
just what "implementation-defined" means.

However, a flag used at compile time may be considered as selecting a
different C implementation (similarly, it is often asserted that the
ANSIness of gcc depends on whether the flags "-ansi -pedantic" are used).
So in that case, the conversion is still constant within a particular
implementation.

And ANSI C provides no run-time call to change the IEEE float rounding
mode; so if a programmer uses such a call, the program is not strictly
conforming and we don't have to think about it further.

So Paul's examples do not show that "implementation-defined" can include
behavior dependent upon a flag.
-- 
Mark Brader   | Nature is often much more interesting than we would like her
msb@sq.com    | to be.  However when we finally do understand something, we
SoftQuad Inc. | strike our foreheads and cry "Of course!", and then marvel at
Toronto       | how beautifully simple it was all the time.   -- Leigh Palmer

This article is in the public domain.
Apologies if you saw it twice -- a local glitch.