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().
Every programmer should read the source to abort() at some point in their life.
31–40 of 61 posts
Re: Every programmer should read the source to abort() at some point in their life.
#32Why is the outer while(1) loop needed? Seems redundant to me.
You know... just in case.
Re: Every programmer should read the source to abort() at some point in their life.
#33Earlier quoted context omitted.
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.
I admit it's heavily commented, and his usual tangle of preprocessor macros are blissfully absent.
But it contains hints of Drepperification, like the superfluous use of preincrement.
Re: Every programmer should read the source to abort() at some point in their life.
#34Every programmer should implement an operating system and compiler. I did. Now get off my lawn.
stfu
Re: Every programmer should read the source to abort() at some point in their life.
#35I 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().
Since the lock is not guaranteed in the code, the variable is globally defined and the code only ever increases it. This means a step in the chain of killing could get skipped, but that doesn't matter, as there's always a more violent option (or just the infinite loop).
Re: Every programmer should read the source to abort() at some point in their life.
#36Wow, abort() is much more polite than I assumed.
Re: Every programmer should read the source to abort() at some point in their life.
#37I 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++ is atomic in most cases, unless i is an excessively wide integer, in abort I think they lock anyway so it doesn't matter (at least in uclibc)
Re: Every programmer should read the source to abort() at some point in their life.
#38Raymond Chen wrote a classic blog post on how process exits on WinXP. But if you're a developer, know that it's not the same for Win7. http://blogs.msdn.com/b/oldnewthing/archive/2007/05/03/23833...
Re: Every programmer should read the source to abort() at some point in their life.
#39I 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().
On an 8-bit system with 16-bit-wide ints, i++ is almost certainly not atomic (with respect to threads, interrupts, etc.).
A few months ago I fixed this exact bug in a developer's code, on a 8-bit embedded processor.
Re: Every programmer should read the source to abort() at some point in their life.
#40Earlier quoted context omitted.
But you have to admit, his abort is pretty damn easy to read.
I admit it's heavily commented, and his usual tangle of preprocessor macros are blissfully absent. But it contains hints of Drepperification, like the superfluous use of preincrement.
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.