Re: YES on Motion P1788/M0029.02:Level3-InterfaceOnly
On 2012-01-05 16:16:30 -0500, Ian McIntosh wrote:
> VL> wouldn't decorations be the proper way to handle "uninitialized
> variables"?
>
> No, an uninitialized variable is by definition uninitialized by the
> program.
But they could be initialized by the code generated by the compiler.
In IEEE 754, that's the only way sNaN can be used for such variables.
> 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!
> 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. IBM's XLC / XLC++ / XLF compilers have had an option for
> decades to help debug programs by initializing auto (stack) variables to
> any user-specified pattern, and you can choose one that gives you invalid
> pointers or extremely negative integers or obviously bad character strings
> or signaling NaNs or whatever else you need. Similar handling for the heap
> has been suggested. Some other systems have essentially the same
> capability. An early one was the original Watfor Fortran compiler, which
> preinitialized all data memory to have bad parity. A bad parity word isn't
> a Signaling NaN but has a similar effect. Note that this sort of feature
> is NOT part of the language, it's a compiler and/or operating system
> quality of implementation issue, and it's needed by programmers to deal
> with real life problems in large programs.
But what I mean is precisely that the same thing can be done with
decorations: the tool would set some "uninitialized" decoration.
This decoration would be specified by the standard, just like sNaN
is specified in IEEE 754.
> For this to also work for 1788 does NOT require that it be part of
> the 1788 standard. It just requires that 1788 not prohibit it. If
> 1788 is implemented using 754, it can be automatically available via
> the compiler or OS option.
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.
> VL> The fact that they cannot be the result of an operation is one of the
> reasons I proposed to disallow them: this won't be a problem for the
> implementation.
>
> Since they can't be produced by any 754 operation and presumably (the
> standard is not final yet) not by any 1788 operation, there is no advantage
> to disallowing them.
The user might have a way to produce sNaN (depending on what P1788
will contain), at least this is possible in IEEE 754.
> They could only occur if the programmer is trying to find an
> uninitialized variable, probably already cursing and certainly
> cursing us if we make debugging harder by an unnecessary
> restriction. It WILL be a problem for the implementation if they are
> forbidden.
I don't see why.
> 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.
--
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 / Arénaire project (LIP, ENS-Lyon)