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

Groups > comp.compilers > #2204

Re: Optimization techniques

Show all headers | View raw

David Brown <david.brown@hesbynett.no> wrote:
> And there are undefined behaviours which could be given definitions, but
> doing so is not actually a positive thing.  The prime example is signed
> integer overflow.  Since overflowing your integers is almost always an
> error in the code anyway, there are no benefits in giving it defined
> behaviour.

This is completely backwards. If signed overflow was given a defined
behaviour (such as the two's complement result), then compilers for
CPUs which do not implement two's complement operations would have to
generate less efficient code (but does anyone still make such a CPU?).
Any program which guarantees not to overflow would be unaffected. Any
program which expects a two's complement result could now be relied
upon to work correctly, and not suddenly produce random results when
the next version of the compuler comes out!  Any program which
expected a different result (one's complement anyone?)  would need
additional code.

With the current situation, anyone wanting to avoid
undefined behaviour (and don't we all?) has to write code like
this for any signed operation:

signed int sum;
if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
     ((si_b < 0) && (si_a < (INT_MIN - si_b)))) {
   /* Handle error */
} else {
   sum = si_a + si_b;
}

See:

https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

>  But mathematical identities such as associativity and commutativity are
> valid because signed integer overflow does not happen - thus "a * (b +
> c)" can be changed to "(a * b) + (a * c)".

The following slide set discusses some of the problems with undefined
behaviour starting on slide 43:

http://www0.cs.ucl.ac.uk/staff/B.Karp/3007/s2018/lectures/3007-lecture5-C-arith-undef-behav.pdf

Examples of problems include privilege elevation exploits and denial
of service attacks.

There was a discussion about undefined behaviour on this list in
March/April last year. 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/

--
			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
[I don't think there are any ones complement machines left but there are certainly
machines with different word sizes. -John]

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

Thread

Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-25 16:46 +0100
  Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-25 23:01 +0000
  Re: Optimization techniques alexfrunews@gmail.com - 2019-04-26 01:33 -0700
    Re: language design and Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-27 11:56 +0100
    Re: Optimization techniques 0xe2.0x9a.0x9b@gmail.com - 2019-04-27 04:56 -0700
      Re: C language andOptimization techniques alexfrunews@gmail.com - 2019-04-27 19:47 -0700
    Re: reliability features and Optimization techniques Bart <bc@freeuk.com> - 2019-04-28 11:58 +0100
      Re: reliability features and Optimization techniques Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2019-04-29 04:33 -0700
    Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:11 -0700
    Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-07 16:43 +0200
  Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-27 23:01 +0200
    Re: Optimization techniques, C++ numeric representations David Brown <david.brown@hesbynett.no> - 2019-04-29 17:24 +0200
      Re: Optimization techniques, C++ numeric representations Hans Aberg <haberg-news@telia.com> - 2019-04-30 15:01 +0200

csiph-web