Re: [eigen] Signed or unsigned indexing

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Hi Francois,

There is no question that unsigned overflow can already be very dangerous, leading to crashes etc.

"Undefined behavior" is its own class of danger, though. When the compiler sees undefined behavior, it can do absolutely anything... an old version of GCC was emitting code to run some some video game, to illustrate that point.

here is a little 'study' of the actual behavior of compilers on undefined behavior that I made while I was working at a Web browser vendor:

https://raw.githubusercontent.com/bjacob/builtin-unreachable-study/master/notes

That was actually a study of the effect of using __builtin_unreachable. But any kind of undefined behavior is in principle equivalent to that.

As you can see there, it's pretty crazy the optimizations that GCC does when it takes undefined behavior seriously, e.g.
 - removing 'ret' instructions at the end of functions, allowing code to continue running past the end of a function's code!
 - removing bounds checks on switch statements implemented as jump-tables, thus allowing to jump to unintended addresses!

Benoit

2017-01-20 14:04 GMT-05:00 François Fayard <fayard@xxxxxxxxxxxxx>:
Hi Benoit,

Could you please elaborate on why it is dangerous? On most cases I know of, when there is overflow, the signed version leads to unsigned behaviour, and the unsigned version leads to something such as a crash or an infinite loop. In the end, I would say that both cases are equally bad.

Do you have a concrete example where the signed version leads to more dangerous bugs than the unsigned version?

> But from the perspective of software developers, the undefined behavior in signed overflow is danger.
>
> That leads to one of the strongest arguments in favor of unsigned: at least, that has well-defined (wrapping) overflow behavior. That might be 'broken', but it isn't nearly as dangerous as the undefined behavior of signed overflow!
> Benoit






Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/