Displaying 3 results from an estimated 3 matches for "_unpredictable_".
2011 Nov 30
0
[LLVMdev] The nsw story
...at
> undef could take on which would produce the same behavior.
>
Part of the confusion seems to come from overloading "undefined."
The VAX architecture spec nicely dealt with the distinction between
unspecified results and unspecified behavior by consistently using
distinct terms: _unpredictable_ results, and _undefined_ behavior.
An operation producing an unpredictable result could produce any
bit-pattern that fit in the output operand; but it would not trap
or do anything else unfriendly.
An operation causing undefined behavior means anything could happen,
from no-effect to machine meltdo...
2011 Nov 30
2
[LLVMdev] The nsw story
On Nov 30, 2011, at 12:21 PM, Paul Robinson wrote:
> Part of the confusion seems to come from overloading "undefined."
> The VAX architecture spec nicely dealt with the distinction between
> unspecified results and unspecified behavior by consistently using
> distinct terms: _unpredictable_ results, and _undefined_ behavior.
> An operation producing an unpredictable result could produce any
> bit-pattern that fit in the output operand; but it would not trap
> or do anything else unfriendly.
> An operation causing undefined behavior means anything could happen,
> from no...
2011 Nov 29
6
[LLVMdev] The nsw story
The old and popular tradition of "int" being the default all-purpose type
in C hit a snag with the arrival of 64-bit general-purpose architectures,
when, for reasons of memory usage and compatibility, "int" was fixed
at 32 bits. This meant it was no longer the same size as a pointer, the
size of an array index, or the widest native integer type. (Sequence of
events simplified