Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190701140631.GP1506@brightrain.aerifal.cx>
Date: Mon, 1 Jul 2019 10:06:31 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Conditional signal safety?

On Mon, Jul 01, 2019 at 06:21:11AM +0200, Florian Weimer wrote:
> * Markus Wichmann:
> 
> > at work yesterday I had to build an exception handler (a signal handler
> > for SIGSEGV, SIGBUS, SIGILL, and SIGFPE). For my purposes, it was really
> > convenient to just use dladdr() to find out at least what module and
> > function PC and LR were pointing to when the exception happened, so I
> > used that function.
> 
> Are these signals generated synchronously, by running code?  Then the
> rules regarding asynchronous signal safety do not apply.

That's a meaningful distinction if they're generated by accesses in
the application code. If they're generated by accesses from within
standard library functions (e.g. because you passed an invalid pointer
or one to memory that was intentionally setup to generate them) to a
stdlib function, it's just UB, and if you were going to define it,
it'd still be an async signal context just because it's async with
respect to the interrupted state of the stdlib function being
unspecified/unspecifiable.

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.