Re: YES on Motion P1788/M0029.02:Level3-InterfaceOnly
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. I wouldn't favour that, because
C and C++ provide many theoretically insoluble ways to use undefined
values :-(
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 :-(
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).
How would one implement that anyway with Intervals embedded in C, if the
programmer asks the system to preinitialize memory to Signaling NaNs, and
no 1788 or other operation has initialized a variable? Forbid using a
useful debugging option?
No problem since this is seen as undefined behavior. See above.
Close enough.
Regards,
Nick Maclaren.