Re: YES on Motion P1788/M0029.02:Level3-InterfaceOnly
On 2012-01-06 13:20:39 +0000, N.M. Maclaren wrote:
> On Jan 6 2012, Vincent Lefevre wrote:
> >On 2012-01-05 16:16:30 -0500, Ian McIntosh wrote:
> >
> >>In C / C++ and some other languages they are variables in "auto" (on
> >>the stack) or in a block allocated (malloced or newed) from the heap
> >>without the program explicitly initializing them. That also means
> >>the decoration is uninitialized. The whole variable (inf, sup and
> >>decoration) contains random garbage.
> >
> >If the whole variable contains random garbage, how do you expect sNaN
> >be a solution for those variables??? This makes no sense at all!
>
> Not quite. It is perfectly reasonable to require that such variables
> are initialised to a signalling NaN.
If it is (for FP variables), then it is also reasonable to require
that such interval variables be initialized with a decoration
meaning that the variable is not initialized.
Anyway, my point was that sNaN shouldn't be used for Empty, when
it really means Empty and not some uninitialized interval.
> I wouldn't favour that, because C and C++ provide many theoretically
> insoluble ways to use undefined values :-(
Agreed.
> >>Programming languages are unlikely to treat Interval variables
> >>significantly differently than other types, so uninitialized
> >>Interval variables will exist.
> >>
> >>Many compilers or operating systems have some way of helping programmers
> >>with this. ...
>
> Deceptively. While it can help with 80% of such bugs, it doesn't
> save more than 20% of effort. The trouble is that too many people
> think that it is reliable :-(
>
> >There's no problem if P1788 prohibits the use of sNaN: if a variable
> >is uninitialized in C and similar languages, one has undefined behavior,
> >so that the implementation can do whatever it likes in this case.
>
> Actually, no, it's not that simple - there are things that you can do
> with undefined values that do not create undefined behaviour :-(
Well, this was ambiguous. I should have said: if a FP variable is not
initialized, neither explicitly nor implicitly (thus this excludes
static objects in C, in particular), then the memory contents is not
specified, and an implementation (e.g. a compiler) is allowed to put
whatever it likes, e.g. sNaN. Important note: if this is done by some
other tool, like a debugger, this doesn't mean that one would get the
"expected" behavior, since the compiler might have done optimizations
(such as removing apparently dead code, so that some exception will
not occur) based on the fact that the variable was not initialized.
> >The user might have a way to produce sNaN (depending on what P1788
> >will contain), at least this is possible in IEEE 754.
>
> Not quite. The implementation is allowed not to (5.12.1 p. 7).
Sorry, I should have been more accurate. I meant that it can be
possible in languages (at least in C), partly based on the fact
that IEEE 754 specifies the sNaN encoding. In C, this can be done
by storing a sequence of bytes using a union. Of course, this can
only be implementation-defined because IEEE 754 specifies the
encoding only as a bit-string (not as a sequence of bytes).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)