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: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public From: thp@cs.ucr.edu (Tom Payne) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/10 Message-ID: <4kgmgu$jm@galaxy.ucr.edu>#1/1 X-Deja-AN: 146751112 references: <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <4kcer3$mi4@solutions.solon.com> <4kdnvq$3n8@mulga.cs.mu.OZ.AU> followup-to: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu organization: University of California, Riverside newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-10T00:00:00+00:00 List-Id: Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: : seebs@solutions.solon.com (Peter Seebach) writes: [...] : >Further, that behavior is a flat out bug; it is never correct, and the : >portability problem lies in the program, not the language spec. The : >program needs to be fixed. : : No, the portability problem is the different behaviour of the program, : when run on different systems. It does not "lie in" the program -- it : makes little sense to speak of behaviour "lying in" a program. The : behaviour is not something that has a single cause -- rather, it has a : multitude of causes, some direct, and some indirect. The problem is : caused by the program AND by the implementation AND by the language spec. At the risk of mentioning the obvious, when the standard leaves a behavior "undefined", it increases the portability of the langauge (i.e., the ease of generating efficient object code on a large range of architectures) at the expense of portability of programs written in that language (i.e., same behavior under different implementations). "Undefined behavior" takes the implementors off the hook in many difficult situations and give them more control in others. Their life is made more comfortable at the expense of the programmer, who looses control and the ability to know what to expect in certain circumstances. Implementors are well represented in the C and C++ committees and the balance of power is reflected in the standards these groups have generated. Ada by contrast was developed under the auspices of the U.S. government's Department of Defense, a customer, not a vendor, of progrmming language implementations. I've not read the Ada standard but I'd expect the balance of power to be reflected in far less "undefined behavior." The problem shows up in real situations: In C++ AFAIK there is no efficient way for an exception at the hardware level to generate an exception (in the C++ sense) on the part of the running program -- the running must poll a volatile atomic variable to see if the exception has occurred. This obviously makes the langauge, as defined in the standard, unacceptable for use in the area of, say, embedded systems. Even in scientific progrmming, however, one would like to be able to throw an exception out of a matrix manipulation routine when the underlying hardware detects a floating point exception, and polling for such an occurrence would involve unacceptable overhead. Tom Payne (thp@cs.ucr.edu)