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