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

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

Re: In the end, rason will come

Show all headers | View raw

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. But so ... solution is same as with your #2.

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

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

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

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

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

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