www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C undefined behaviour

reply bearophile <bearophileHUGS lycos.com> writes:

by Chris Lattner himself (main author of LLVM):

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://www.reddit.com/r/programming/comments/h9rf9/what_every_c_programmer_should_know_about/

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://www.reddit.com/r/programming/comments/hbepu/what_every_c_programmer_should_know_about/

The third blog post is yet to be shown.

From my tests the Clang -fcatch-undefined-behavior -ftrapv switches work, they
are going to be used for my C code. But I'd like a similar switch for unsigned
values too, because currently it doesn't catch situations like:


Using:
clang -fcatch-undefined-behavior -ftrapv


#include <stdio.h>
int main(void) {
    long x = 2000000000;
    unsigned y = 2000000000;
    long z = x + y;
    printf("z = %ld\n", z);
    return 0;
}


Outputs the wrong result still:
z = -294967296

This attitude of C compiler writers (and C language standard writers) is
terrible (this also is why I use Python everywhere I can).

Bye,
bearophile
May 15 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
This follows:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=136205

Third part and last one:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
http://www.reddit.com/r/programming/comments/hgk12/what_every_c_programmer_should_know_about/

This third article gives possible ideas for future safety improvements of D
design :-) Every time you fix/avoid some of those problems, you erode away some
costly and sometimes painful debugging time. So this work is ethically sound
too.

Bye,
bearophile
May 21 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Regarding what I have said here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=136205

A person has said me that Clang had the -ftrapu compiler switch to trap
unsigned overflow too, but Chris removed it, because unsigned overflow is
defined in the C standard. The discussion:

http://comments.gmane.org/gmane.comp.compilers.clang.devel/4469

The comment by Chris Lattner:


 I'm sorry I was too terse.  I don't want clang IR generation  
 supporting language features that are not useful for C/C++ etc.   
 Previously we had run-ins where you were trying to adapt the objc  
 runtime generation code to work with your objective-smalltalk  
 compiler, and this was causing the code to get contorted and be slow.
 
 I don't think it is ever a good idea to turn random unsigned  
 multiplies into overflow checked ones, so I don't think that -ftrapu  
 is useful for C programmers, so I think it should be removed.
 
 I *would* be supportive of an attribute on integer types that let  
 programmers "opt in" to overflow checking on particular values.  This  
 would be incredibly cool and generally useful because it doesn't break  
 the semantics of C.  I just am opposed to a global option that changes  
 how C works.


D doesn't need to follow such C design decisions. And even for C, Chris has
broken and improved over some sclerotic design decisions of C compiler
designers (even on little things, like Clang doesn't need a switch to compile
C99 code!). So probably the generation of compiler writers successive to Chris
will improve further. Compiler technology seems to move forward about ten times
slower than other computer technology :-)

Bye,
bearophile
May 21 2011