Re: Constexpr evaluation of heavy stuff

From	Ben <ben.usenet@bsb.me.uk>
Newsgroups	comp.lang.c++
Subject	Re: Constexpr evaluation of heavy stuff
Date	2022-05-20 12:32 +0100
Organization	A noiseless patient Spider
Message-ID	<871qwo5tib.fsf@bsb.me.uk> (permalink)
References	(7 earlier) <727d656f-7e08-4be2-a0c9-c2dc9d29b00cn@googlegroups.com> <t67jvc$1q94$1@gioia.aioe.org> <978b4a0b-0740-4b01-96b0-4b9e52e0de1an@googlegroups.com> <87o7zs5wlt.fsf@bsb.me.uk> <6caff9be-a81b-4a8e-b302-add0b3207e99n@googlegroups.com>

Show all headers | View raw

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 20 May 2022 at 11:26:07 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
>> 
>> > On Friday, 20 May 2022 at 09:37:19 UTC+1, Juha Nieminen wrote: 
>> >> Malcolm McLean <malcolm.ar...@gmail.com> 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. 
>> 
> You frequently generate co-ordinates that go outside of image bounds
> when working with images. It's easier to deal with this if the values
> to the top and left go negative instead of wrapping to high positive
> values.

But the bounds of the image won't correspond to the signed wrapping so
this has to be coded and checked for anyway.

> As a general rule, it's better if all integers are signed.

As a general rule, general rules are too general to be considered rules.

-- 
Ben.

Thread

Constexpr evaluation of heavy stuff Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-18 16:17 -0700
  Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 09:19 +0200
    Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-19 11:59 +0200
      Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 12:37 +0200
        Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-19 14:49 +0200
          Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-19 06:19 -0700
            Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-19 20:32 +0300
              Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 01:12 -0700
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 08:37 +0000
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 02:21 -0700
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 11:25 +0100
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 12:47 +0200
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 12:13 +0100
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 14:27 +0200
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-20 06:33 -0700
                Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-20 17:15 +0300
                Re: Constexpr evaluation of heavy stuff Christian Gollwitzer <auriocus@gmx.de> - 2022-05-20 18:57 +0200
                Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-20 22:31 +0300
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-21 21:56 +0200
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-21 23:24 -0700
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-22 04:56 -0700
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-22 06:15 -0700
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-22 21:46 +0200
                Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-22 23:23 +0200
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-22 16:26 -0700
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-23 17:24 +0200
                Re: Constexpr evaluation of heavy stuff Richard Damon <Richard@Damon-Family.org> - 2022-05-23 19:41 -0400
                Re: Constexpr evaluation of heavy stuff scott@slp53.sl.home (Scott Lurndal) - 2022-05-24 16:15 +0000
                Re: Constexpr evaluation of heavy stuff Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-24 05:37 -0700
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 04:19 -0700
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 12:32 +0100
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 10:40 +0000
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 12:31 +0200
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 10:43 +0000
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 14:52 +0200
          Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 15:34 +0200
    Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 17:03 +0200
  Re: Constexpr evaluation of heavy stuff Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-19 08:53 -0700
    Re: Constexpr evaluation of heavy stuff Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-05-19 18:33 +0200

csiph-web