4 ms·

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

rm445 15y ago
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.
p9idf 15y ago
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.
singular 15y ago
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.
- raldi 15y ago
  (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.
- ristretto 15y ago
  Thanks. I could never guess it could be optimized out.

rm445 15y ago

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.

p9idf 15y ago

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.

singular 15y ago

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.

raldi 15y ago
(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.
ristretto 15y ago
Thanks. I could never guess it could be optimized out.