mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Hi and a few questions
Date: Sun, 20 May 2012 17:20:08 -0400	[thread overview]
Message-ID: <20120520212008.GB163@brightrain.aerifal.cx> (raw)
In-Reply-To: <3093865.QEH9na1OAA@main.pennware.com>

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


  reply	other threads:[~2012-05-20 21:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-20 17:03 Richard Pennington
2012-05-20 17:21 ` Rich Felker
2012-05-20 19:57   ` Richard Pennington
2012-05-20 20:49   ` Isaac Dunham
2012-05-20 21:25     ` Rich Felker
2012-05-20 17:53 ` Szabolcs Nagy
2012-05-20 20:01   ` Richard Pennington
2012-05-20 20:44   ` Richard Pennington
2012-05-20 21:20     ` Rich Felker [this message]
2012-05-20 20:28 ` Szabolcs Nagy
2012-05-20 20:36   ` Richard Pennington
2012-05-21  1:54     ` Isaac Dunham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120520212008.GB163@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).