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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: David Thompson Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Sun, 26 Apr 2015 07:38:33 -0400 Organization: Poor Message-ID: References: <87h9t95cly.fsf@jester.gateway.sonic.net> <04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com> <871tk1z62n.fsf@theworld.com> <87twwxxgke.fsf@theworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx02.eternal-september.org; posting-host="1be7d8ad8e7f3e5fc77a1d7b89d8968a"; logging-data="3567"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/moLaXkf4xDd0VHskSxzdGTZVF2ITAVak=" X-Newsreader: Forte Agent 3.3/32.846 Cancel-Lock: sha1:4gge0lHx79IgGxUDWgYqxYVrlU0= Xref: news.eternal-september.org comp.lang.ada:25637 Date: 2015-04-26T07:38:33-04:00 List-Id: On Fri, 03 Apr 2015 13:33:21 -0400, Bob Duff wrote: > "J-P. Rosen" writes: > > > [In C] A number of things (handling of integer overflows, > > semantics of %, dereferencing the null pointer...) are defined in the > > language as "like the machine does" (this is spelled: implementation > > defined). Unless it has changed in recent versions of C ? > > No, no C standard has ever said "like the machine does". Those things > are defined as "undefined behavior" in C, and that does not mean "like > the machine does", it means "anything can happen" (as far as the C > standard is concerned). "Like the machine does" is not even meaningful > in a high-level language. What the machine does depends on what code > the compiler generates. For example, Actually standard C had and has three levels: - undefined behavior: anything can happen. This can include the program crashing (and even the whole system or device crashing if not using some kind of protected mode), corrupting data, or the favorite hyperbolic example on comp.lang.c: causing demons to fly out of your nose. (Google if interested.) Like Ada erroneous. - unspecified (usually result): one from a set of things defined by the standard occurs, but you don't know which. A common example is the evaluation of operands to a nonsequencing two-operand operator, or arguments in a function call: they can be done in any order, even overlapped, but each one must be evaluated exactly once. (Although some confusion occurs because multiple _assignments_ within one statement are usually undefined behavior; this often occurs as a result of using nested assignment operators like a++ and a*=b that also yield a useful value to an outer expression. In Ada, like most(?) other HLLs, assignment is a statement and never directly nested.) - implementation-defined: like unspecified, but the implementation must _document_ the choice, or at least any constraints on the choice. These freedoms _commonly_ are used by a compiler to do whatever the machine does for the simplest, fastest, and/or otherwise preferred code, but the compiler can do other and sometimes surprising things if it "wants" i.e. the compiler writer chooses to for whatever reason. One example has changed: % was and is defined in terms of / i.e. x%y = x-(x/y)*y for nonzero y. But / was originally implementation-defined if any operand negative; C99 changed / to standardly round-to-zero and thus % to be same sign as numerator, or zero. Division and remainder by 0 were/are undefined behavior (in practice often trap/abort). Also C _signed_ integer overflow was/is undefined (and in practice _usually_ wraparound) but _unsigned_ overflow was/is modulo 2^nbits with nbits implementation-defined. Floating overflow was/is undefined by C, but may be (and often is) defined by IEEE aka IEC[60]559.