[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120520212008.GB163@brightrain.aerifal.cx>
Date: Sun, 20 May 2012 17:20:08 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Hi and a few questions
On Sun, May 20, 2012 at 03:44:24PM -0500, Richard Pennington wrote:
> On Sunday, May 20, 2012 07:53:16 PM Szabolcs Nagy wrote:
> [snip]
> > "conformance/interfaces/pthread_key_create/1-2.c:44: error: control reaches
> > end of non-void function" there are a couple of similar bad tests
>
> This one might be real. I think the declaration of
>
> void pthread_exit(void *);
>
> should be
>
> void pthread_exit(void *) __attribute__ ((__noreturn__));
>
> for gcc and clang. Does musl allow this type of attribute usage? I don't see
> many attributes used in the header files.
In principle I'm not opposed to adding attributes under #ifdef
__GNUC__ when they have clear benefits to the generated code. If exit
functions are such a case, I would consider it.
However, on the uClibc list it was noted that the noreturn attribute
makes WORSE code from a debugging standpoint by making it impossible
to backtrace an exit in the debugger (which can be useful when there's
a breakpoint or crash in an atexit or pthread cleanup function).
Also, while POSIX does not permit conforming applications to do this,
musl allows longjmp out of cleanup handlers (which might have been
invoked via pthread_exit or cancellation) and uses this allowance
internally in the POSIX timer code (to allow reuse of the timer thread
for realtime robustness, i.e. no danger that a thread cannot be
created).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
