Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every programmer should read the source to abort() at some point in their life.

reddit.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Every programmer should read the source to abort() at some point in their life.

#51

Post by praptak »

Jabbles wrote: post #48
masklinn wrote: post #26

Earlier quoted context omitted.

And OSX's, which is rather similar to FreeBSD's but adds: * Writing to NULL * Writing to address 1 (unaligned write) * Writing to text space (read-only machine code) * Dividing by 0 * More violence than SIGABRT (SIGILL, SIGBUS) http://www.opensource.apple.com/source/Libc/Libc-262/stdlib/...

Since dereferencing a null pointer and dividing by 0 are undefined by C, is the compiler required to emit the code for them? In practice, does it?

In practice, (int )0 (how do I escape asterisks on HN?) and similar are popular idioms for "segfault here". Making them break is not an optimization any compiler maintainer would bother to make - it requires a special case and there don't seem to be any benefits to justify the effort.

Re: Every programmer should read the source to abort() at some point in their life.

#52

Post by singular »

ristretto wrote: post #15
p9idf wrote: post #10

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

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

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.

Re: Every programmer should read the source to abort() at some point in their life.

#53

Post by IgorPartola »

cube13 wrote: post #44
IgorPartola wrote: post #31

I may be wrong, but I thought that in a multithreaded environment, doing i++ is not atomic and could result in garbled data. Instead you should use __sync_add_and_fetch. However, I have no idea if it should be used inside abort().

>I may be wrong, but I thought that in a multithreaded environment, doing i++ is not atomic and could result in garbled data. Instead you should use __sync_add_and_fetch. However, I have no idea if it should be used inside abort(). This is only true if the variable in question's memory is accessed by multiple threads at the same time, and there isn't any locking or synchronization method used to protect the memory. I…

You are right. Re-reading the code, I see that it re-acqures the lock.

Re: Every programmer should read the source to abort() at some point in their life.

#54

Post by raldi »

singular wrote: post #52
ristretto wrote: post #15

Earlier quoted context omitted.

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

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) T…

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

Re: Every programmer should read the source to abort() at some point in their life.

#55

Post by raldi »

jethroalias97 wrote: post #18
p9idf wrote: post #10

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

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

0 cast as a pointer is not necessarily 0x0.

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

Re: Every programmer should read the source to abort() at some point in their life.

#56

Post by raldi »

cube13 wrote: post #44
IgorPartola wrote: post #31

I may be wrong, but I thought that in a multithreaded environment, doing i++ is not atomic and could result in garbled data. Instead you should use __sync_add_and_fetch. However, I have no idea if it should be used inside abort().

>I may be wrong, but I thought that in a multithreaded environment, doing i++ is not atomic and could result in garbled data. Instead you should use __sync_add_and_fetch. However, I have no idea if it should be used inside abort(). This is only true if the variable in question's memory is accessed by multiple threads at the same time, and there isn't any locking or synchronization method used to protect the memory. I…

The lock must be released because the same thread might reenter abort() in the signal handler, and without a release in the parent abort(), the program would hang.

Re: Every programmer should read the source to abort() at some point in their life.

#57

Post by ristretto »

singular wrote: post #52
ristretto wrote: post #15

Earlier quoted context omitted.

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

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) T…

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

Re: Every programmer should read the source to abort() at some point in their life.

#58

Post by kelnos »

jordanb wrote: post #47
kelnos wrote: post #40

Earlier quoted context omitted.

When I don't care about the result, I always write preinc/decrement too. Sure, it's superfluous on any non-braindead compiler (it should be able to see that you don't care about the result of a postincrement and elide the temporary), but it's just habit at this point. I fail to see how it reduces or changes readability though. Sounds like you just have an axe to grind with Drepper.

I don't have anything personal against Drepper. I've never had any direct experience with him of any kind. I thoroughly enjoyed his article about memory. He is obviously an extremely intelligent and knowledgeable guy. I am afraid that he is too clever by half though, insofar as good code is clean and readable first, and clever second. Every time I've had an opportunity to interact with the glibc codebase I'm dismayed…

That's unfortunate; I'll have to look at some glibc code sometime. Could be fun... or, as you point out, dismaying :-/

Re: Every programmer should read the source to abort() at some point in their life.

#60

Post by [deleted] »

praptak wrote: post #51
Jabbles wrote: post #48

Earlier quoted context omitted.

Since dereferencing a null pointer and dividing by 0 are undefined by C, is the compiler required to emit the code for them? In practice, does it?

In practice, (int )0 (how do I escape asterisks on HN?) and similar are popular idioms for "segfault here". Making them break is not an optimization any compiler maintainer would bother to make - it requires a special case and there don't seem to be any benefits to justify the effort.

[deleted]
Post reply on HN