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

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

Re: In the end, rason will come

Show all headers | View raw

On 31/07/2019 23:22, Öö Tiib wrote:
> On Wednesday, 31 July 2019 16:30:21 UTC+3, David Brown  wrote:
>> On 31/07/2019 12:48, Öö Tiib wrote:
>>>
>>> I agree that that signed arithmetic should not overflow
>>> in good code but it seems hard to find (or to teach) programmers
>>> who write good code in that respect. So there are often bugs with
>>> it and so I would often prefer crash (or have SIGFPE raised)
>>> instead of wrapping.
>>>
>>
>> I see a number of reasons why two's complement wrapping for signed
>> arithmetic is a bad idea.
> 
> I was almost certain that you are one who is against it considering
> what you have written before.
> 
>>
>> 1. It hinders optimisations.  When you have division involved, you lose
>> several associative properties of integer arithmetic.  And you lose all
>> sorts of basic identities that exist when you assume no overflow, such
>> as "x > y <=> (x + z) > (y + z)".
> 
> That is true, (like I said), there are several optimizations that
> assume that integer arithmetic does not overflow and it will be
> tricky to indicate to compiler that it may do such optimizations
> in conforming mode.

Such optimisations won't be tricky - they will be completely impossible.

> But so ... solution is same as with your #2.
>

Of course.  Any defined behaviour on overflow restricts optimisations. 
It's good to be able to choose what you want in different circumstances 
- if you want traps on overflow to aid debugging, you don't mind the 
cost in optimisations.

>> 2. It makes alternative overflow behaviour wrong and non-conforming.
>> That means a compiler that has traps on overflows for safer coding or
>> during debugging, is suddenly no longer correct C++.
> 
> The compiler vendors have never cared that with certain options
> their compiler is not conforming. Quite popular is to let to turn
> off exceptions, to turn off RTTI and so on. I do not think that turning
> off wrapping signed integers will be different in any way.
> 

It will be a completely different thing.  And I think that is so obvious 
it doesn't need more explanation.

>> 3. It gives broken and incorrect code a defined behaviour, making it
>> harder for compilers and static analysis tools to inform the programmer
>> and help find mistakes.  Instead of being able to tell you that you've
>> overflowed your integer constant (or constexpr) calculations, you'd have
>> to put the compiler in non-conforming modes first.
> 
> Please elaborate. There are piles of warnings that a well-formed
> program with fully well-defined behavior will receive with -Wall
> and most warnings in -Wextra are such plus there are more warnings
> I like that neither of those settings turns on. No non-conforming
> modes are needed. So why should warning about potentially wrapping
> integer suddenly cause different situation?
> 

It is conceivable that compilers will have warnings for overflows on 
signed arithmetic, even when it is fully defined - but I think it is 
unlikely except with a view to compatibility for current standards. 
Compilers don't warn when unsigned arithmetic overflows, because it is 
fully defined.

The difference is that when someone writes, for example, "if (a = 1)", 
they have almost certainly made a mistake.  So it is not unreasonable 
for compilers to warn about it (and not unreasonable that it requires a 
non-default flag to get the warning, since it is valid C or C++ code). 
But if and when signed integer overflow becomes fully defined with 
wrapping behaviour, it is no longer a mistake.  How is the compiler 
supposed to guess what was intentional behaviour and what was likely to 
be a programmer error?

>> 4. Integer arithmetic that overflows is almost always in error - even if
>> the results are defined (by the language, compiler flags, etc.).  If you
>> have a pile of 2147483647 apples and put another apple on the pile, a
>> result of -2147483648 is about the silliest answer you could possibly
>> give.  Raising an error or saturating would be far more likely to be
>> correct.
> 
> That option I would also love like I said above.
> 

That cannot be an option if wrapping is the defined behaviour.

It is fine to have flags that add semantics to the language in place of 
undefined behaviour.  It is not fine to have flags that give completely 
different semantics to something the language defines.  This is not like 
enabling or disabling particular features, such as exceptions or RTTI 
(features which are typically only disabled for niche uses, such as 
resource limited embedded systems).

>> 5. It gives the impression that signed integer arithmetic is now "safe"
>> and can be carried out without as much care and attention as you had to
>> do when there were nasal demons lurking round the bend.  This is, of
>> course, nonsense - it merely hides some classes of errors under the
>> carpet where they are harder to find.
> 
> It is frequently same with unsigned integers. On lot of cases when
> these overflow then it is defect.
> 

Agreed.  I would be happy for unsigned arithmetic to be undefined on 
overflow in most cases.  However, there are occasional situations where 
wrapping behaviour is clearly useful and correct, so it is important 
that there is /some/ way to get it.  If unsigned arithmetic were not 
defined with wrapping in C and C++, there would have to be another way 
to do it for these occasional uses.

>> So I am against defining the results of signed integer arithmetic
>> primarily for code safety and correctness reasons, and secondarily for
>> performance reasons.
> 
> But you put performance reason as #1 in above list. ;)
> 

It was not ordered by importance (or what I feel is most important). 
Correctness always trumps efficiency, and aids to correctness are 
therefore high on my list of important features.

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

Thread

In the end, rason will come Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-31 10:14 +0200
  Re: In the end, rason will come "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-07-31 01:25 -0700
    Re: In the end, rason will come James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-31 07:58 -0400
      Re: In the end, rason will come Siri Cruise <chine.bleu@yahoo.com> - 2019-07-31 05:14 -0700
      Re: In the end, rason will come Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-31 22:35 +0000
    Re: In the end, rason will come "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-31 14:59 +0200
  Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 03:48 -0700
    Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-07-31 15:29 +0200
      Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 14:22 -0700
        Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-01 23:25 +0200
          Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-08-01 19:53 -0700
            Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-02 20:46 +0200
              Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-08-05 02:56 -0700
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-06 14:32 +0200
                Re: In the end, rason will come Manfred <noname@add.invalid> - 2019-08-07 16:05 +0200
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 17:00 +0200
                Re: In the end, rason will come "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-07 18:39 +0200
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 21:15 +0200
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 21:20 +0200
                Re: In the end, rason will come Ralf Goertz <me@myprovider.invalid> - 2019-08-08 12:14 +0200
                Re: In the end, rason will come Ralf Goertz <me@myprovider.invalid> - 2019-08-08 12:21 +0200
          Re: In the end, rason will come Christian Gollwitzer <auriocus@gmx.de> - 2019-08-02 07:41 +0200
    Re: In the end, rason will come Keith Thompson <kst-u@mib.org> - 2019-07-31 13:05 -0700
      Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 15:48 -0700
        Re: In the end, rason will come Keith Thompson <kst-u@mib.org> - 2019-07-31 16:32 -0700
          Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 19:21 -0700
      Re: In the end, rason will come Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-02 08:10 +0200
  Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-06 14:54 +0200

csiph-web