4 ms·
Or it was undefined behavior in your code, like depending on the evaluation order of function parameters, or one of mine, testing an array element before testin
by zlynx 6y ago
Or it was undefined behavior in your code, like depending on the evaluation order of function parameters, or one of mine, testing an array element before testing the index was within bound.
Broken: table[table_i].values[j] && j<category_map_count && to_i<category_array_len;
Fixed: j<category_map_count && table[table_i].values[j] && to_i<category_array_len;
Optimizer: "j was used to access values array, j outside array would be undefined behavior, therefore it must have been within the array boundaries and does not need to be tested."
Oh, and threading bugs where some variable that should have been mutex locked or made atomic gets moved in or out of a register depending on the phase of the moon, causing other threads to fail to notice changes to that variable...but add a debug line and it suddenly works.
- mjg59 6y agoA wonderful example of this was some Linux kernel code that ended up causing a security vulnerability. It was something approximating: int foo(struct data *data) { struct member *member = &data->member; if (data == NULL) { return -EINVAL; } // Do stuff } Assigning a value to member is just a matter of taking data and adding the value of member, so won't explode if data is NULL since it's not actually dereferencing that address. But this is still in undefined behaviour territory, so gcc assumed that we must know that data could never be NULL and optimised out the check. This sort of thing is why I have definite feelings about the use of C in security sensitive contexts.
- dnautics 6y agohahah good point. The bug I discovered was in the erlang compiler, which does not have UB (in the language being compiled), and threading bugs are either rarer or obvious.