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

Groups > comp.lang.c++ > #84215

Re: Constexpr evaluation of heavy stuff

Show all headers | View raw

David Brown <david.brown@hesbynett.no> writes:

> On 20/05/2022 12:25, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@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.
>
> I see two advantages of UB.
>
> One is that if your code never leads to overflows (and that should
> usually be the case, once you have everything tested and debugged), it
> gives the compiler some extra optimisation opportunities.  But the big
> one, IMHO, is that it means tools can treat the overflow as a mistake
> in the code.  That means you can use a tool that gives debugging aids
> when the error occurs, without changing the defined behaviour of
> correct code.

The suggestion was to prefer a program to be undefined rather than
fiddle about with well-defined but fancy modulo arithmetic (I am
paraphrasing -- the context has been lost).

It was not about UB in general.

> If I suspect my code has an error leading to signed integer overflow,
> I can use a toolchain with a "sanitizer" to catch the overflow and
> then fix the problem.

Yes, but would you avoid unsigned int and prefer signed in order to get
this "advantage"?  Seems an odd choice to me.

-- 
Ben.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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