C is popular as intermediate language. This means that some compilers generate C and use a C compiler as backend. Wikipedia lists several languages, which use C as intermediate language: Eiffel, Sather, Esterel, some dialects of Lisp (Lush, Gambit), Haskell (Glasgow Haskell Compiler), Squeak's Smalltalk-subset Slang, Cython, Seed7 and Vala.
When C is used as backend the features needed from a C compiler are different from the features that a human programmer of C needs. One such feature is the detection of signed integer overflow. It is not hard, to detect signed integer overflow with a generated C program, but the performance is certainly not optimal. Signed integer overflow is undefined behavior in C and the access to some overflow flag of the CPU is machine dependent. So the generated C code must recogize overflow before it happens or use unsigned computations and recognize the overflow afterwards. I have doubts that this leads to optimal performance. The C compiler is much better suited to do signed integer overflow checks. The C compiler can do low level tricks, that would be undefined behavior in C, and the C compiler also knows about overflow flags and other details of the CPU. Maybe the CPU can be switched to a mode where it traps signed integer overflow for free. The gcc compiler option -ftrapv promises to do exactly that, but it seems broken. At least my test suite shows that both gcc version 4.6.3 and 4.8.1 fail to detect integer overflow with -ftrapv. The detection fails even for addition and subtraction. I know that 4.6.3 and 4.8.1 are old, but I found nothing in the internet that tells me that the situation is better now. So for gcc as C compiler backend -ftrapv cannot be used and overflow checking in the generated C code is necessary. Clang supports -ftrapv reliably. Signed integer overflow raises the signal SIGILL, which can be catched. Btw. SIGILL seems to be a better choice, because under windows (7) SIGABRT causes some text to be written to the console. Is it possible to choose a -ftrapv signal? A sanitizer such as ubsan is good as tool to find errors in C programs. But I don't think that ubsan is well suited to do overflow detection with maximum performance. Is just not the goal of this tool. The argumantation that nobody uses -ftrapv is self-fulfilling prophecy. How can someone expect that a buggy feature is used. The counterexample is clang, where -ftrapv works and is also used (E.g. by the integer overflow detection of Seed7). Conclusion: Signed integer overflow detection with -ftrapv is NOT something that nobody uses. It is an important feature. Especially when C is used as intermediate language. When it works it results in a significant speed up of signed overflow detection. A sanitizer has a different purpose and cannot be used as replacement. I can offer some help with this issue: I have test programs for cases with integer overflow and for cases where the result is as big or as small as possible without causing an overflow. The test programs are not written in C, but are licensed with the GPL, and it would be possible to convert them to C with reasonable effort. Maybe this is not necessary, because clang must have some test suites for -ftrapv. Greetings Thomas Mertes -- Seed7 Homepage: http://seed7.sourceforge.net Seed7 - The extensible programming language: User defined statements and operators, abstract data types, templates without special syntax, OO with interfaces and multiple dispatch, statically typed, interpreted or compiled, portable, runs under linux/unix/windows.
