> Pedantically:
> > unsigned a,b,c,d;
> I assume you mean int; undefined overflow is perfectly well defined in
> C99 (6.2.5p9, if you are bored).
No, I mean unsigned.
I'm not looking for overflow errors. I just want to assert they don't
happen.
> Ultimately, the front-end would have to communicate the semantics
> about about may or may not overflow. By the time things are translated
> into LLVM, the semantics are precise; it would be a mistake to
> diagnose overflow because the LLVM instructions are well defined and
> optimization passes and other transformations (for example, code
> created by the front-end but not something the user wrote directly)
> are free to create them (and most certainly do).
Again, don't want to diagnose them, I want to assert they do not happen
in symbolic expressions. It's for under-constrained execution. Assume
x is under-constrained and we see something like:
unsigned x;
int a[20];
...
if(x > 20)
a[x]++;
We can prove that x causes an error and so flag it.
Unfortunately, we can't do this for variants of:
unsigned x,y;
int a[20];
...
// x and y are under-constrained
if(x > 20 && y > 20)
a[x+y]++;
Since if x+y overflows it can go in bounds for a. I would like to assert
overflow does not happen so we can find this case (which is what a large
portion of unvetted-input security holes look like)
Thanks for the clang pointer; good to keep in mind for longer term.
Dawson
