TalkChess.com

Rein Halbersma wrote:Avoiding shifting on signed integers is probably a good rule of thumb. E.g. to use shifting on signed integers in order to get cheaper multiplications and divisions is something that your compiler will already do for you (and if it doesn't, it's probably not worthwhile anyway).

But note that not shifting signed integers at all it is slightly more restrictive than necessary. Shifting positive values by valid shift amounts is typically OK, and only if you shift negative signed values do you land in undefined (for left-shifts) or implementation-defined (for right-shifts) behavior.

Codesquid wrote:

bob wrote:I've grown up in an era of trusting the compiler. You got a bug, it is almost certainly a programming bug.

Undefined behavior in your program is a programming bug.

That era seems to be coming to an end, because a change to a compiler really should not change program behavior, if the original compiler was worth a crap...

See it the other way around: Different compilers expose different bugs in your program, thus increasing overall quality if those bugs are fixed.

bob wrote:Back to square 1. The apple change to libc did NOT fix anything. It broke thousands of existing applications. What is sad is that they COULD have fixed the bug, removed the undefined behavior, and now all those thousands of applications would STILL work, and would no longer fall into any undefined behavior pitfall. They COULD have done that. But they didn't.

wgarvin wrote: I think there's probably a market for compilers with a "secure" mode, where they generate slightly less performant code but never perform these optimizations that rely on undefined behavior never happening. You can already get some of that using compiler options, such as -fwrapv (or -ftrapv) or -fno-strict-aliasing. They should take that to the logical conclusion and build us a mode that treats ALL undefined behavior as having some implementation-specific behavior (and bonus points if they spell out clearly what it is and commit to not changing it in the future). Maybe the standards committee or some research group will produce a spec that the compiler vendors could target for it. A lot of developers who make safety-critical embedded devices, avionics, medical equipment, OS kernels, etc. would be better served by a "safer" compiler rather than fastest possible generated code.

UndefinedBehaviorSanitizer (ubsan), a fast undefined behavior detector, has been added and can be enabled via -fsanitize=undefined. Various computations will be instrumented to detect undefined behavior at runtime. UndefinedBehaviorSanitizer is currently available for the C and C++ languages.

syzygy wrote:I don't know how helpful and complete it will be, but gcc-4.9 will have an UB detector:

UndefinedBehaviorSanitizer (ubsan), a fast undefined behavior detector, has been added and can be enabled via -fsanitize=undefined. Various computations will be instrumented to detect undefined behavior at runtime. UndefinedBehaviorSanitizer is currently available for the C and C++ languages.

http://gcc.gnu.org/gcc-4.9/changes.html

bob wrote: What is sad is that they COULD have fixed the bug, removed the undefined behavior, and now all those thousands of applications would STILL work, and would no longer fall into any undefined behavior pitfall

syzygy wrote:

bob wrote:Back to square 1. The apple change to libc did NOT fix anything. It broke thousands of existing applications. What is sad is that they COULD have fixed the bug, removed the undefined behavior, and now all those thousands of applications would STILL work, and would no longer fall into any undefined behavior pitfall. They COULD have done that. But they didn't.

Indeed back to square 1. The bug was in your code, see C89, section 4.11.2.3 and see C99 and see C11. Apple cannot fix bugs in your code. The most Apple can do is force you to fix it. They did. Maybe they weren't nice to you, but that does not change the fact that the bug was in your code.

All you have to do is admit that your code had a bug. But we already know that this is beyond you.

syzygy wrote:I don't know how helpful and complete it will be, but gcc-4.9 will have an UB detector:

UndefinedBehaviorSanitizer (ubsan), a fast undefined behavior detector, has been added and can be enabled via -fsanitize=undefined. Various computations will be instrumented to detect undefined behavior at runtime. UndefinedBehaviorSanitizer is currently available for the C and C++ languages.

http://gcc.gnu.org/gcc-4.9/changes.html

hgm wrote:

syzygy wrote:Then you should use a compiler that makes a promise that it will deal with integer overflow in a particular way. For gcc, just get used to invoking it with -fwrapv. I'm sure you won't mind the loss in efficiency, especially on loops using an int as loop variable.

Ah, it is good to know that this destructive behavior can be switched off. And of course there won't be any loss in efficiency whatsoever, as I would never write any code that could benefit from 'code-wrecking optimizations'.

I would not write "for(i=1; i>=0; i += i)" when I meant "while(1)". I wonder how many people would... So making the compiler assume this was meant, no matter by which amount of contrived reasoning, doesn't count as sane behavior, IMO.