Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:71 vs 79 seconds (Score 1) 449 449

Carlsen didn't seem entirely sure that it had started

This is normal: when you start the clock, there is no visual indicator until 1 second has passed, and the time ticks down to the next second. So there is that short period where you aren't sure if your press registered or not.

Comment Re:TFA does a poor job of defining what's happenin (Score 1) 470 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 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 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 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)

Often statistics are used as a drunken man uses lampposts -- for support rather than illumination.

Working...