Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | >
| > | > C has been a portable assembler for years before it got normalized and
| > | > optimizing compilers took over.
| > |
| > | 18 years. And now it has been 17 years since C has been standardized so
| > | you can say C has been standardized now for half its life. 18 years is a
| > | long time when it comes to computers. I know one problem is that most
| > | people who learn C don't learn about the undefined behaviors until they
hit
| > | it.
| >
| > But did you learn the history of how and why those "undefined
| > behaviour" came into existence in the first place?
|
| Tell us then.
The question was not rhetorical, but genuine.
I gather from your answer that you don't know; that is OK. C existed
before it got a standard (which was expected to be finalized circa
1983-84, but miraculously got delayed for a couple of years). C
existed before C++ (which unofficially turned 25 a couple of months ago).
It is incorrect to assert that
# Over those 17 years, C has not changed that much.
The C standard, in effect, has an appendix (Annex H) that was not
there in the C89 edition, and that talks about the very specific issue
at hand
H.2.2 Integer types
[#1] The signed C integer types int, long int, long long
int, and the corresponding unsigned types are compatible
with LIA-1. If an implementation adds support for the LIA-1
exceptional values ``integer_overflow'' and ``undefined'',
then those types are LIA-1 conformant types. C's unsigned
integer types are ``modulo'' in the LIA-1 sense in that
overflows or out-of-bounds results silently wrap. An
implementation that defines signed integer types as also
being modulo need not detect integer overflow, in which
case, only integer divide-by-zero need be detected.
[...]
Returning to my question, which was genuine, you might get a sense of
what the C committee decided to cover by "undefined bahviour" by
looking at "The Rationale":
http://www.lysator.liu.se/c/rat/a.html#1-7
Undefined behavior gives the implementor license not to catch
certain program errors that are difficult to diagnose. It also
identifies areas of possible conforming language extension: the
implementor may augment the language by providing a definition of
the officially undefined behavior.
| It was added to disable the already added optimizations in 2003 (2
| years before VRP was added), why did nobody raise the issue then?
maybe you don't remember this is not the first time the issue is
coming up -- almost invariably with the same answers. That is OK too.
Next time, we will ask why are discussing this only now instead of x
years ago?
-- Gaby
