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

21–30 of 61 posts

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

#21

Post by pluies »

ars wrote: post #16
jordanb wrote: post #4

Earlier quoted context omitted.

Most of the code in glibc has been heavily Dreppered.

What does Dreppered mean?

It's probably a quip referring to Ulrich Drepper, a kernel hacker whose personality seems to be quite controversial according to a quick Google search. I'd love to hear the GP explain it further though.

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

#22

Post by drv »

ars wrote: post #16
jordanb wrote: post #4

Earlier quoted context omitted.

Most of the code in glibc has been heavily Dreppered.

What does Dreppered mean?

Ulrich Drepper is the maintainer of glibc; I don't know what the comment is intended to mean, though.

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

#23

Post by ristretto »

raldi wrote: post #20
ristretto wrote: post #14

Why is the outer while(1) loop needed? Seems redundant to me.

The link specifically asks that question -- there are some good guesses in the comments.

the one in line 87. It looks like it might be added later because it's not even indented, but clearly it doesn't serve any purpose and it doesn't make it more readable (you can tell the function never returns from the second while(1) loop).

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

#24

Post by jordanb »

ars wrote: post #16
jordanb wrote: post #4

Earlier quoted context omitted.

Most of the code in glibc has been heavily Dreppered.

What does Dreppered mean?

Ulrich Drepper tends to write software that is easy for him to read (one would hope) -- but is very difficult for anyone else to follow.

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

#25

Post by re »

ristretto wrote: post #23
raldi wrote: post #20

Earlier quoted context omitted.

The link specifically asks that question -- there are some good guesses in the comments.

the one in line 87. It looks like it might be added later because it's not even indented, but clearly it doesn't serve any purpose and it doesn't make it more readable (you can tell the function never returns from the second while(1) loop).

> it's not even indented

It's an issue of mixed tab-space indentation, with tabs being displayed at 4 spaces instead of the 8 spaces they were intended to be.

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

#26

Post by masklinn »

cpeterso wrote: post #12

For comparison, here's FreeBSD's abort(): http://svnweb.freebsd.org/base/head/lib/libc/stdlib/abort.c?... And GNU glibc's abort(): http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=stdlib...

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

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

#27

Post by rm445 »

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.

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.

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

#28

Post by ajross »

masklinn wrote: post #26
cpeterso wrote: post #12

For comparison, here's FreeBSD's abort(): http://svnweb.freebsd.org/base/head/lib/libc/stdlib/abort.c?... And GNU glibc's abort(): http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=stdlib...

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

Looks to me like glibc and FreeBSD are the only ones that flush stdout, which I'd view as a bug on the other systems...

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

#29

Post by jrockway »

jordanb wrote: post #24
ars wrote: post #16

Earlier quoted context omitted.

What does Dreppered mean?

Ulrich Drepper tends to write software that is easy for him to read (one would hope) -- but is very difficult for anyone else to follow.

But you have to admit, his abort is pretty damn easy to read.

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

#30

Post by p9idf »

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.

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.
Post reply on HN