Hacker News Reader

Comment by foldr | Hacker News Reader

This idiom used to trigger a panic is interesting. Is it also used in the original GLib?

    fprintf(stderr, "BUG: _g_hash_table_find_free_slot: Failed to find an empty slot.");
    int *ptr = NULL;
    *ptr = 0;

I'd have thought this was somewhat dangerous, as dereferencing a NULL pointer is undefined behaviour, so that the compiler is technically free to eliminate '*ptr = 0' (with the result that the code will continue executing).

View on HN

Back when GLib was written, compilers didn't do anything fancy with code like this, so this was a completely reliable way to trigger a segmentation violation. As always, even though the standard says you should not do that, people write to the actual implementation.

Nowadays, I would expect the entire branch to be marked unreachable, i.e. the whole block would be deleted and if actually reached, nothing would happen.

FWIW from a quick testing both GCC and Clang generate a segfault with full optimizations as long as this isn't the only code in the program (e.g. in my test i put this in a separate function that printf'd some message before doing the assignment).

Also GCC does generate the segfault even if this is the only code (in main) but Clang writes code that exits the program with some error code instead of segfaulting in all optimization levels except 0 (with -O0 it generates the segfault like GCC).

abort() exists for a reason.

Especially given that it could just call abort(), which has instead a well-defined behavior.

This is/was sometimes used as a debugger trap, i remember a coworker of mine having a t-shirt once that was like "KEEP CALM AND (void*)0 = (void)0" :-P

This most likely is an unexpected failure. Indicating bug in algorithm or memory corruption. Like "Failed to find empty slot, while logic flow says I should have."

That's definitely the intent of the code, but I don't think it's correct to do it this way, as the compiler can just optimise out the null pointer dereference.

Thanks for pointing this out, I just replaced it with exit(1).

Yeah, you're right. That's undefined behaviour, which is a compiler free for all in terms of unwanted effects.

I think this is unique to CLib, not from GLib.

Reply on news.ycombinator.com