Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior Date: Tue, 30 Apr 2019 14:46:40 +0200 Organization: A noiseless patient Spider Lines: 58 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-04-047@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-039@comp.compilers> <19-04-042@comp.compilers> <19-04-044@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="91104"; mail-complaints-to="abuse@iecc.com" Keywords: design, errors Posted-Date: 30 Apr 2019 22:17:58 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <19-04-044@comp.compilers> Xref: csiph.com comp.compilers:2231 On 29/04/2019 18:10, Christian Gollwitzer wrote: > 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) 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. It is really incredibly simple (at least in this case). Do the multiplications using types that won't overflow. That might be an unsigned type if its range is suitable (not because it has defined overflow behaviour, but use it if it has enough range) or a bigger signed integer type. There are plenty of cases where it is difficult to write code that is efficient even on poorer compilers, and correct code so that it works on good compilers. No one claims that programming is always easy. And sometimes the best solution is code that is not portable or correct by the standards, but works well with the implementations you need to use. Most code, after all, is only ever compiled on the one compiler. > 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. > All C++ compilers with any self-respect support 64-bit integer types. Do you think it's reasonable to reject any image dimension greater than 2,000,000,000 ? I do. I am not saying that "use long long int" is always the answer, of course - nor saying that the answer is always that simple. I am not even saying that portable solutions are always right - sometimes non-portable choices give the best results. But there /is/ always an answer - one that is correct, with defined behaviour (even if it is only defined by the compiler, rather than the standards).