Post by j***@verizon.netDo you think a differently worded standard would make it possible to get a usable implementation of C out of an implementor who lacked good judgement? I sincerely doubt it.
Any standard which tries to define a single category of conforming programs
that will run usefully on all conforming implementations must necessarily
be so loose in what it promises as to be useless for non-toy programs on
large platforms, or so severe in its platform requirements that smaller
platforms can't implement it.
On the other hand, a standard could define a category of Selectively
Conforming programs such that:
1. A conforming implementation given a Selectively Conforming program
would have two options:
a. Process it in defined fashion consistent with the Standard
b. Announce in Implementation-Defined fashion that it cannot do so
and discontinue processing without releasing nasal demons.
2. Almost anything that could be done by a C program today could be done
with a Selectively Conforming program, and
3. Most existing implementations would be readily adaptable to accept
Selectively Conforming programs whose requirements coincide with the
ways those implementations would "naturally" behave, at least when
invoked with proper compiler flags.
If e.g. a program contains a directive demanding that integer overflows
have no side-effects, and that the lower (int_size) bits of the result be
correct when stored or when coerced to smaller types, but not demanding
that temporary results be truncated, then given:
flag = x1*x2 > x3;
a conforming implementation would have two options:
1. Process the code so that it evaluates the expression correctly in
cases that don't overflow, and yields 0 or 1, chosen
2. Refuse to execute the program at all.
Common sense would suggest that quality implementations targeting silent-
wraparound two's-complement hardware should use the first option, but even
a deliberately-obtuse implementation would be able to do nothing worse than
refuse to run a program which it "should" be able to run without difficulty.
Post by j***@verizon.netI'll pass on the "common sense" issue - that's just a code phrase for "thinks the same way I do", and I certainly would not be particularly interested in an implementation produced by an implementor who thinks the same way you do.
I judge an implementation's quality on factors like the ability to run code
written for other implementations, or the amount of code a programmer would
have to write to accomplish various tasks. While there are exceptions,
almost every program I've written has had two fundamental requirements:
1. When given valid data, produce correct output.
2. When given invalid data, don't launch nuclear missiles.
If a wide range of outputs would be equally acceptable in response to
invalid inputs, a compiler which is given the chance to select freely
among several ways of evaluating an expression may be able to produce
better code than a compiler which is fed either:
flag = (long long)x1*x2 > x3;
or
flag = (int)((unsigned)x1*x2) > x3;
If it doesn't matter whether the expression yields 0 or 1 in case of
overflow, why not let the compiler pick whichever would be more efficient?