Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Ben Newsgroups: comp.lang.c++ Subject: Re: Constexpr evaluation of heavy stuff Date: Fri, 20 May 2022 11:25:50 +0100 Organization: A noiseless patient Spider Lines: 48 Message-ID: <87o7zs5wlt.fsf@bsb.me.uk> References: <727d656f-7e08-4be2-a0c9-c2dc9d29b00cn@googlegroups.com> <978b4a0b-0740-4b01-96b0-4b9e52e0de1an@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="cdab4b3beb056ab549fca8770562cf4a"; logging-data="8864"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xrULiWWn6AhBfHCqg8TrB3V1kx1X1zwk=" Cancel-Lock: sha1:rqyj7UgU8qQz+9uc4zMo72zuD/8= sha1:ykbxTGKdn6BCafSrk6riOsEKZiI= X-BSB-Auth: 1.c1c89c44cda048b38414.20220520112550BST.87o7zs5wlt.fsf@bsb.me.uk Xref: csiph.com comp.lang.c++:84210 Malcolm McLean writes: > On Friday, 20 May 2022 at 09:37:19 UTC+1, Juha Nieminen wrote: >> Malcolm McLean wrote: >> > The snag is that to use it, you have to be able to put the compiler into a >> > mode where it traps on overflow instead of silently wrapping. Most >> > compilers don't have such a mode. >> I'm not entirely sure what the point of that would be. What exactly should >> happen in such a program if an unsigned arithmetic operation overflows or >> underflows? Should the program end? Should the code throw an exception? >> (What would you do if such an exception happens?) How should the program >> behave in such a situation? >> >> Also, should bit-shifting to the left trap if a 1-bit gets shifted out? >> Ostensibly multiplying by a power of 2 should trap if it overflows. >> Should bit-shifting to the left also do so (given that it's effectively >> the exact same thing)? >> >> Maybe it should behave like a few other programming languages which switch >> from hardware-register-sized integers to software multiprecision integers >> on any overflow? (But even then, what about underflow?) >> >> If you want integers that grow as needed, just use GMP? >> > Say we've got this code. > > int width = getinteger(): > int height = getinteger(); > int Npixels = width* height; > > There's a potential vulnerability there if Npixels wraps. An attacker > might be able to construct an input file that causes the program to > access memory out of bounds in such a way as to cause arbitrary code > to be executed. I found the suggestion (not from you) that UB is an advantage a very odd one. I would consider it too unpredictable to be any practical help. But here, why not just make all the sizes unsigned? You have to do some bounds checking since the data come from a file which can be maliciously constructed, so provided you do that check, a wrapped Npixels will presumably just produce a junk result. And, if you decide to add an overflow check, it's no harder using unsigned. -- Ben.