Golden California Girls said:
Standard" attempts to not impose a restriction it actually does,
because it does require that other standards exist and by reference
those standards become part of "this International Standard." So if
the manual for the implementation exists and says it generates code
to run on the XYZ processor and the XYZ processor has a manual that
says what happens in the case of integer overflow then "this
International Standard" also says what happens in the case of
integer overflow despite (3.4.3p3) "EXAMPLE An example of undefined
behavior is the behavior on integer overflow."
[...]
I don't think so.
The C standard requires an implementation to document certain choices.
It doesn't require it to document that it generates code to run on the
XYZ processor, or to document, directly or indirectly, what happens on
integer overflow. A vendor can certainly provide whatever additional
documentation it likes, but that extra documentation doesn't become
part of the C standard.
And even if it did, your conclusion doesn't follow. For example,
suppose the FooCC implementation's documentation says that it
generates code for the Foo 4200 processor, and the Foo 4200
processor's documentation says that integer overflow wraps around in
the common two's-complement fashion, so that INT_MAX + 1 == INT_MIN.
The FooCC compiler can still perform optimizations and generate code
based on the assumption that integer overflow does not occur. For
example, for this code fragment:
int i = INT_MAX;
i ++;
puts("Hello");
the compiler could legitimately generate code that never prints
"Hello", because the behavior is undefined. This would not violate
either the C standard, the FooCC documentation, or the Foo 4200
processor documentation.
If the FooCC compiler's documentation states that it doesn't perform
such optimization, but the compiler actually does so, then the
compiler is violating its own documentation -- but that's not a
violation of the C standard.
I am not disagreeing what you are saying, but would like to offer my
point of view behind the rationale behind leaving something undefined.
The reason makes a lot of sense and is pragmatic:
Le's use the ++ operator as example. It means basically increment
value. The idea is what it would translate to efficient machine code,
ideally, increment instruction. It might combine into something bigger
with constant propagation and other optimizations that might or might
not be going on. That is irrelevant so I won't go into that tangent in
more detail.
The _point_ is that if C standard would require a *specific* behaviour
of the overflow, this means ALL implementations would be mandated to
invoke that specific behaviour. This means EVERY FUCKING INCREMENT
OPERATOR would add the "guard" code against specific behaviour of
overflow for architectures where the behaviour isn't in line with the
standard's requirements. This would mean overhead.. the designers
wanted to avoid this overhead being FORCED by the wording of the
standard.
It isn't like the standard COULDN'T require a lot of things, but those
requirements were relaxed in favour of performance. This leaves some
burden on the programmer; there is no substitute for knowing what you
are doing. Now, why choose performance then? Why not safety? A good
question. I cannot speak on behalf of the authors of the standard, but
what I do know is that the more compromises are made the less useful
the language would be for the purposes I feel that it was designed
for: a close to metal abstraction of the underlying machine
architecture(s).
They would have shot themselves in the foot if they compromised too
much; that isn't fact but opinion and I Might Be Wrong (tm) but that's
how I feel based on various factors that are biased from my personal
experience. xD
Of course, such shotcomings would be "easy" to work around in specific
architectures by writing the code in assembly, but that would defeat
the whole purpose of writing the code in C to begin with.
I should have used fewer words because this is basically a very simple
issue, at least from my point of view. What I do not understand is how
come not more contributors to this thread don't realize the same very
simple point? I have to conclude that most likely I am full of shit
and wrong and shouldn't have posted. Oh well.
