Hacker News Reader

Comment by p9idf | Hacker News Reader

Plan 9's abort causes an access fault, causing the current process to enter the `Broken' state. The process can then be inspected by a debugger. Pretty elegant.

http://plan9.bell-labs.com/sources/plan9/sys/src/libc/9sys/a...

View on HN

In practical terms, does this differ significantly from killing the process and leaving a coredump?

Beautiful! The gurus do not disappoint.

Very elegant, though in some cases 0x0 is addressable, in which case, the abort never happens.

Not, as it happens, on plan 9 systems where the kernel marks that area as not accessible. This could fail, conceivably, but then you're in much deeper stuff.

0 cast as a pointer is not necessarily 0x0.

The spec says it equals NULL, which, too, is not necessarily 0x0.

again, what's with the while()? even if it doesnt cause a segmentation fault, there's a chance it will evaluate to 0.

I'm not a plan 9 programmer, but to me it looks 'cute' (in the sense of attractive to some people but annoying to others) - that form of abort() would only be used on systems where that operation is known to abort the process, but enclosing it in a while simply makes it apparent that there is no alternative to trying it.

On a more prosaic note, perhaps

    for(;;)
        *(int *)0;

generates a compiler warning that the programmer wanted to avoid.

As far as I know, the kernel programs the MMU so that dereferencing 0 will always fault. I could be wrong, as my understanding of the kernel is limited. I am not sure of the purpose of the loop, but to me it make it unavoidably obvious that the function never returns.

gcc, at least, optimises out the null deref for both:-

    *(int *)0;

and:-

    for(;;)
        *(int *)0;

So the first bit of code does nothing, and the second slips off into an infinite loop.

I suspect that treating expressions that demonstrably lack side effects (other than the intended segfault here of course) as statements is undefined, and hence these are getting optimised out (even with -O0).

Clearly with:-

    while(*(int *)0)

The expression is being evaluated and is therefore not elided, I guess the choice of while is to 'be cute' as others have suggested, and I guess the world is sane in plan 9 and 0 is readable so you can't get a situation where it escapes the loop. Perhaps there is a deeper reason here that I am missing, however.

(int *)0 is not defined as a pointer to memory address 0x0 on architectures that support such an address.

0 cast as a pointer is defined by the spec to always be the NULL pointer, which on such architectures would have a value other than 0x0 and not point anywhere addressable.

Thanks. I could never guess it could be optimized out.

Reply on news.ycombinator.com