Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

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

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

"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

>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

>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)

Slashdot Top Deals

In the realm of scientific observation, luck is granted only to those who are prepared. - Louis Pasteur