Forgot your password?
typodupeerror

Comment: Re:TFA does a poor job of defining what's happenin (Score 1) 470

by Old Wolf (#45275885) Attached to: How Your Compiler Can Compromise Application Security

I think you must be mis-remembering the details slightly. The comma operator is a sequence-point, so "tmp" must be assigned the value of "a", and f() and g() must both be called with a value that is the value of "a" converted to the type of "tmp". The two functions can be called in either order though (or in parallel) but there is no issue there.

Of course, the compiler can do anything it likes so long as the program's output is equivalent to what I just described. So, for example, it might not allocate a memory location to "tmp", it could just push the value of "a" onto a register and then call f and g with it. Or if f or g do nothing and have no side-effects, the assembly code might not show calls to f and g. But there is no way you could know these things by running the program, which is the whole point.

Comment: Re:TFA does a poor job of defining what's happenin (Score 1) 470

by Old Wolf (#45275849) Attached to: How Your Compiler Can Compromise Application Security

"Overflows of unsigned values" is NOT undefined. You can assign out-of-range values to unsigned types, and also perform arithmetic operations which exceed the bounds of the type; and the value is adjusted using modular arithmetic.

Some would be facetious and say that "unsigned types cannot overflow", meaning that they always have well-defined behaviour on operations that would generate an out-of-range value, but that's just an issue of pedantry with English.

Comment: Re:TFA does a poor job of defining what's happenin (Score 4, Insightful) 470

by Old Wolf (#45275821) Attached to: How Your Compiler Can Compromise Application Security

>The dereference is undefined, and therefore

Stop right here. Once undefined behaviour occurs, "all bets are off" as they say; the remaining code may have any behaviour whatsoever. C works like this on purpose , and it's something I agree with. It means the compiler doesn't have to insert screeds of extra checks , both at compile-time and run-time.

There are plenty of other languages you can use if you want a different language definition :)

Comment: Re:TFA does a poor job of defining what's happenin (Score 2) 470

by Old Wolf (#45275775) Attached to: How Your Compiler Can Compromise Application Security

>a == b is not a use of the argument that has been invalidated

Yes it is. Evaluating the expression "a" causes undefined behaviour if "a" is
indeterminate. "a" is considered to no longer have a value, any attempt to
refer to its value causes UB. (It has the same status as a variable that has
been defined but not initialized, i.e. "int a;"

The only thing that can be done with "a" thereafter is to assign a new value to it
(or take its address, or do "sizeof a" .. can't think of any other exceptions)

panic: can't find /

Working...