Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Martin Ward Newsgroups: comp.compilers Subject: Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Date: Thu, 12 Apr 2018 09:52:59 +0100 Organization: Compilers Central Lines: 66 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-04-044@comp.compilers> References: <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> <2018Mar31.160556@mips.complang.tuwien.ac.at> <2018Mar31.195714@mips.complang.tuwien.ac.at> <18-04-018@comp.compilers> <18-04-033@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="38048"; mail-complaints-to="abuse@iecc.com" Keywords: design, optimize, errors Posted-Date: 12 Apr 2018 11:16:00 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2062 On 10/04/18 19:07, Gene Wirchenko wrote: > On Tue, 10 Apr 2018 11:07:44 -0400 (EDT), "Walter Banks" > wrote: > > [snip] > >> This can be especially true while developing optimization a surprising >> number of new optimizations do not have the intended effect on old >> functioning programs. > > I am a compiler non-expert. Could you give some non-trivial > examples (or point to some), please? As I understand it, a major cause is the 199 or so cases of "undefined behaviour" in the C standard. People write programs which rely on the compiler doing a particular thing, then an optimisation is introduced which "exploits" the undefined behaviour (usually to delete code or tests), and the program stops working as expected These posts give some examples: https://blog.regehr.org/archives/213 https://blog.regehr.org/archives/759 Gcc may optimize out tests for buffer overflows because of integer overflows: https://lwn.net/Articles/278137/ Quote: if (buffer + len >= buffer_end) die_a_gory_death("len is out of range\n"); Here, the programmer is trying to ensure that len (which might come from an untrusted source) fits within the range of buffer. There is a problem, though, in that if len is very large, the addition could cause an overflow, yielding a pointer value which is less than buffer. So a more diligent programmer might check for that case by changing the code to read: if (buffer + len >= buffer_end || buffer + len < buffer) loud_screaming_panic("len is out of range\n"); This code should catch all cases; ensuring that len is within range. There is only one little problem: recent versions of GCC will optimize out the second test (returning the if statement to the first form shown above), making overflows possible again. So any code which relies upon this kind of test may, in fact, become vulnerable to a buffer overflow attack. This behavior is allowed by the C standard, which states that, in a correct program, pointer addition will not yield a pointer value outside of the same object. So the compiler can assume that the test for overflow is always false and may thus be eliminated from the expression. [The desire for efficiency over mathematical analysis takes us back to the other topic ("language design after Algol 60") :-)] -- Martin Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4