Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2062

Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format

Show all headers | View raw

On 10/04/18 19:07, Gene Wirchenko wrote:
> On Tue, 10 Apr 2018 11:07:44 -0400 (EDT), "Walter Banks"
> <walter@bytecraft.com> 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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format "Walter Banks" <walter@bytecraft.com> - 2018-04-10 11:07 -0400
  Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Gene Wirchenko <genew@telus.net> - 2018-04-10 11:07 -0700
    Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format Martin Ward <martin@gkc.org.uk> - 2018-04-12 09:52 +0100
      Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2018-05-05 20:28 +0200

csiph-web