Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[dewar@cs.nyu.edu (Robert Dewar)]

James says

"No. When it says "undefined", it means "undefined". There's no way to make
undefined behavior portable, that's why it's undefined."

Actually, things are not quite so simple. In practice compiler vendors
often go to quite a bit of trouble to make sure that things that people
expect to work, do in fact work they way they expect, even if the standard
says that the behavior is undefined. For example, in Fortran-66, it was
undefined what happened in a DO loop if the end-points were the "wrong"
way round, but in practice the expectation was that the loop would execute
once, so all F66 compilers I know work that way. Similarly in Fortran,
people expect large arrays to be passed by reference, and count on it, so
even though the standard says that it is undefined whether they are passed
by reference or value, all compilers do in fact use pass by reference and
a lot of highly portable code depends on this fact. Highly portable here
is not some kind of theoretical label about conformance, it is an empirical
observation that the code works on all platforms.

Almost all languages have some level of expectations about what works that
go beyond the standard. For example, in C, people do all sorts of things
with pointers that are undefined in ANSI terms, and yet the resulting
programs are in fact highly portable.

In Ada, as another example, there is a strong expectation that if an
out parameter is not assigned in a procedure, then its valud is undefined
and should not be accessed on return, but in fact it is permissible to
raise Program_Error in this case. Ada/Ed used to do this, and it caused
major chaos with a lot of otherwise portable programs. Yes, the programs
were technically wrong, but in the real world, Ada/Ed changed, not all
the programs out there.

A competent compiler tries to implement 100% of the required standard
functionality, plus as much as possible of the expected behavior that
goes beyond this standard, consistent with not damaging the quality
of code, or the performance of the compiler, too severely.

The examples above are just scattered examples, every language I know
has quite a long list of such "common beliefs" that are in fact wrong.

A more delicate problem arises when an existing compiler has bugs with
respect to the standard, and you are trying to be compatible with both
the standard and the existing compiler. In this case, some delicate
compromises may be necessary.