GCC Undefined Behavior Sanitizer

[ketmar via Digitalmars-d]

On Fri, 17 Oct 2014 09:46:48 +0000
via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> It is just plain wrong to let integers wrap by default in an 
> accessible result. That is not integer behaviour.
do you know any widespread hardware with doesn't work this way?

yet i know very widespread language which doesn't care. by a strange
coincidence programs in this language tend to have endless problems
with overflows.

> The correct 
> thing to do is to inject overflow checks in debug mode and let 
> overflow in results (that are accessed) be undefined.
the correct thing is to not turning perfectly defined operations to
undefined ones.

> Otherwise 
> you end up giving the compiler a difficult job:
> 
> uint y=x+1;
> if (x < y){…}
> 
> Should be optimized to:
> 
> {…}
no, it shouldn't. at least not until there will be something like
'if_carry_set'.

> In D (and C++) you would get:
> 
> if (x < ((x+1)&0xffffffff)){…}
perfect. nice and straightforward way to do overflow checks.

> In D it is even worse since you are forced to use a fixed size 
> modulo even for int, so you cannot do 32 bit arithmetic in a 64 
> bit register without getting extra modulo operations.
why should i, as programmer, care? what i *really* care about is
portable code. having size of base types not strictly defined is not
helping at all.

> So, "undefined behaviour" is not so bad
yes, it's not bad, it's terrible. having "undefined behavior" in
language is like saying "hey, we don't know what to do with this, and
we don't want to think about it. so we'll turn our problem into your
problem. have a nice day, sucker!"

> You could for instance say that overflow on ints leads to an 
> unknown value, but no other side effects. That was probably the 
> original intent for C, but compiler writers have taken it a step 
> further…
how is this differs from the current interpretation?

> D has locked itself to Pentium-style x86 behaviour.
oops. 2's complement integer arithmetic is "pentium-style x86" now... i
bet x86_64 does everything in ternary, right? oh, and how about
pre-pentium era?

> Unfortunately 
> it is very difficult to have everything be well-defined in a low 
> level programming language. It isn't even obvious that a byte 
> should be 8 bits
it is very easy. take current hardware, evaluate it's popularity, do
what most popular hardware does. that's it. i, for myself, don't need
a language for "future hardware", i need to work with what i have now.
if we'll have some drastic changes in the future... well, we always can
emulate old HW to work with old code, and rewrite that old code for new
HW.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141017/40f8d3f9/attachment.sig>