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

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

Re: Constexpr evaluation of heavy stuff

Show all headers | View raw

On 20/05/2022 13:13, Ben wrote:
> 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.

Sorry, I misunderstood.  Yes, I agree - you don't want undefined 
behaviour in the final code.  But you also don't want behaviour that is 
defined, but wrong for the code - as is often the case for unsigned 
integer overflow.  Using signed int, along with suitable debugging 
tools, might make it easier to find and fix problems than if you have 
used unsigned ints.

> 
>> 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.
> 

Debugging is always a bit of an art-form (it has famously been said to 
be a harder than writing the code in the first place).  Certainly I 
would consider making such a change to a buggy program in order to find 
a problem, but it is unlikely that I'd pick signed over signed in the 
first place just to allow such debugging.  But then, it's rare that 
overflows occur in my code at all (at least compared to other bugs!).

I have, however, used sanitizers trapping signed integer overflow to 
find bugs in other peoples' code on a couple of occasions.

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