[cfe-dev] david's integer overflow stuff

[David Chisnall]

On 17 Sep 2010, at 23:24, Chris Lattner wrote:

> You're adding a major new feature to the compiler.  In addition to discussion of whether or not it is a good thing, it should be decided if it's the right way to solve the problem, and the patch should include documentation.  You've skipped all of this.  The previous behavior in the last two releases had the exact same problems.

I included a lot of documentation in the original patch, including example of usage, but these were not committed anywhere.  I'm happy to add them, if you can point me to where clang options are meant to be documented outside of the code (I only see documentation on warnings in the user manual).

> I appreciate that the new approach is much more minimal, and I like the design much better than the old.  Please propose some documentation for it.  Also, why does the handler return a value instead of aborting?  I don't see how this is useful.

In this thread, I have already given two cases where it used:

1) In LanguageKit, we promote the overflowed result to an object.  This is useful when implementing Smalltalk, JavaScript, Python, and so on compilers with LLVM.

2) In a calloc()-like function, if the calculation overflows you can substitute 0.  malloc() will then return NULL and it's just appears like you don't have enough memory (which is true, although in the more specific case that you don't have enough address space).  Or some other marker value can be used, so code outside the handler can check for overflow by checking this marker after each operation.

Another one from the CERT paper:

3) It can be used to implement saturation semantics for arithmetic.

And another:

4) It lets you run tested code in permissive mode, where you use the result of the overflowed operation, but use something like libunwind to dump a stack trace to a log somewhere before continuing.  This lets you observe the result of continuing with the overflow (i.e. the check doesn't affect the program's semantics) and check whether anything bad actually happens.  

> I don't see how this affects adoption.  If they haven't adopted it yet, then a change from 2.7->2.8 won't affect them.

Because the major negative comment that is raised when I suggest people adopt clang is that they don't want to be tied in to Apple's compiler.  It's much harder to convince them that clang is a community project that Apple is the largest contributor when the official policy is that issues that affect Apple code are show stoppers and patches that break Apple code are summarily reverted rather than having trivial fixes applied, while patches that break non-Apple code do not require any code review before committing (as long as Apple's stuff is fine) and are not considered release-blockers.

When you, as project leader, are willing to intentionally remove a feature, knowing that people are using it (as you said in the commit log where you removed this), just before a release, without discussion, it makes it very difficult to describe clang as a community project.

David