4 ms·

C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.

by kps 3y ago

jsmith45 3y ago
Yeah. In hindsight for a fair bit of it, it could have been sensibly changed to implementation defined behavior, or to constrained unspecified behavior. (Constrained such that people know what the possibilities are, but the compiler need not document its choice, and might not make the same choice in all circumstances. The latter could allow for scenarios where letting an optimizer do the faster thing when detectable, and what the hardware natively does otherwise, for example. Obviously still a potential footgun, but less of one than full undefined behavior).
tialaramex 3y ago
This makes no sense because C89 is defined for execution on a abstract machine, something which doesn't exist and thus has no hardware. Such beliefs are however compatible with the inveterate C programmer excuse that their nonsense programs should be correct if only the standards committee, compiler vendors, OS designers, and everybody else in the known universe were not conspiring to defeat their clear intent.
- kps 3y ago
  From the C89 Rationale, “The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.”
  - tialaramex 3y ago
    > many operations are defined My emphasis. Undefined Behaviour is not an example of operations being defined.

C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.

by kps 3y ago

C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.

Yeah. In hindsight for a fair bit of it, it could have been sensibly changed to implementation defined behavior, or to constrained unspecified behavior. (Constrained such that people know what the possibilities are, but the compiler need not document its choice, and might not make the same choice in all circumstances. The latter could allow for scenarios where letting an optimizer do the faster thing when detectable, and what the hardware natively does otherwise, for example. Obviously still a potential footgun, but less of one than full undefined behavior).

tialaramex 3y ago

This makes no sense because C89 is defined for execution on a abstract machine, something which doesn't exist and thus has no hardware. Such beliefs are however compatible with the inveterate C programmer excuse that their nonsense programs should be correct if only the standards committee, compiler vendors, OS designers, and everybody else in the known universe were not conspiring to defeat their clear intent.

kps 3y ago
From the C89 Rationale, “The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.”
- tialaramex 3y ago
  > many operations are defined My emphasis. Undefined Behaviour is not an example of operations being defined.