Displaying 3 results from an estimated 3 matches for "_undefined_".
2011 Nov 30
0
[LLVMdev] The nsw story
...hich 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 meltdown.
I always thought the...
2011 Nov 30
2
[LLVMdev] The nsw story
..., 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-effect to machine meltdo...
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