From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/08 Message-ID: #1/1 X-Deja-AN: 146415210 references: <4k9qhe$65r@solutions.solon.com> <828964950snz@genesis.demon.co.uk> <4kbfup$2vd@news1.mnsinc.com> <4kbl5i$p3@mordred.gatech.edu> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-08T00:00:00+00:00 List-Id: 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.