News for hackers. Stuff that matters.
Re:Don’t assume that safety comes for free: a Swift case study by dispose13432 on Tuesday December 06, 2016 @02:19PM (#13117434)
>Note that C has some really ugly behavior here. Signed overflow is undefined behavior, which means that the compiler doesn't need to check for it, but also that it can assume it never happens and optimized based on that. Many programmers don't realize this, or don't notice that they've accidentally written code that depends on overflow behavior, which can lead to many entertaining bugs: https://lwn.net/Articles/511259/

That's because different CPUs behave differently. To avoid undefined behavior, you have to have an "if" at every +.

Re:Don’t assume that safety comes for free: a Swift case study by tomovo on Tuesday December 06, 2016 @02:24PM (#13117482)
Sarcarsm? In some cases you can just do sanity checks on your inputs and use larger number formats for doing sums. Depends on the use case.
Re:Don’t assume that safety comes for free: a Swift case study by jandrese on Tuesday December 06, 2016 @03:06PM (#13117828)
You would also be hard pressed to find a modern architecture that doesn't use twos complement for signed integers.

That said, rolling over on a signed integer is almost always an error, although luckily it is usually one of the easier ones to detect in the debugger. Big negative numbers are a dead giveaway.

Re:Don’t assume that safety comes for free: a Swift case study by dispose13432 on Tuesday December 06, 2016 @07:48PM (#13119608)
It's easy to detect in the debugger.

The danger is

signed int x; cin>>x; if(x+1<x){return OVERFLOW;}

will, in modern optimizing compilers, never return OVERFLOW

There were quite a few security holes introduced by the compiler with that.

-----

The only problem is to make a standard, one has to define that MAX_INT+1 = 0 or something. Then, whenever one does

signed int x;

cin>> x;

signed int y = x+1;

really turns into

signed int = 0;

if ( x < MAX_INT)

y= x+1

else

y = 1;