Re: Optimization techniques and undefined behavior

Christian Gollwitzer <auriocus@gmx.de>
Mon, 29 Apr 2019 18:10:26 +0200

          From comp.compilers

Related articles
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-25)
Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-04-26)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-04-28)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-04-29)
Re: Optimization techniques and undefined behavior bc@freeuk.com (Bart) (2019-04-29)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-04-29)
Re: Optimization techniques and undefined behavior auriocus@gmx.de (Christian Gollwitzer) (2019-04-29)
Re: Optimization techniques and undefined behavior bc@freeuk.com (Bart) (2019-04-29)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-04-30)
Re: Optimization techniques and undefined behavior david.brown@hesbynett.no (David Brown) (2019-04-30)
Re: Optimization techniques and undefined behavior bc@freeuk.com (Bart) (2019-05-01)
Re: Optimization techniques and undefined behavior bc@freeuk.com (Bart) (2019-05-01)
Re: Optimization techniques and undefined behavior anw@cuboid.co.uk (Andy Walker) (2019-05-02)
[55 later articles]
| List of all articles for this month |

From: Christian Gollwitzer <auriocus@gmx.de>
Newsgroups: comp.compilers
Date: Mon, 29 Apr 2019 18:10:26 +0200
Organization: A noiseless patient Spider
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> 19-04-021 19-04-023 19-04-037 19-04-039 19-04-042
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="66143"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, debug
Posted-Date: 29 Apr 2019 22:43:50 EDT

Am 29.04.19 um 17:08 schrieb David Brown:
> I don't write signed integer expressions that overflow -
> barring bugs in my coding.  And thus I don't care what the compiler does
> about them, and have no interest in their consistency.


I find this to be a very bold claim. Maybe you write code where such
things indeed are no issue, but consider the following, seemingly simple
exercise: Write a subroutine which loads a PGM image file and returns a
byte buffer (say, std::vector<uint8_t>) containing the data. An 8 bit
PGM file is trivial to parse, it looks like basically like this:


P5
100 200
255
..jdk hlhdhqkd.. here comes the binary data




The 100 and 200 are the width and height of the image data, the 255 is
the highest possible value (for 16 bit it would be different).
Obviously, you'd read in the width and height, then multiply them to
compute the memory needed for the data, and - oops - how do you make
sure that no overflow occurs? In the past, there had been security
problems in image libraries with exactly this kind of problem: integer
overflow due to unreasonable image sizes.


The simplest thing would be to reject any width or height > 100,000,
claiming that noone can handle this images, but what about an image of
size 200,000 x 3 ? If C++ would provide an easy way to detect / branch
on overflow, for example throw an exception, then this could be handled
easily. I can't see how you can claim that your code never overflows,
unless you don't handle untrusted user input data.


Christian


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.