Re: Conditional signal safety?

[Florian Weimer <fweimer@redhat.com>]

* Rich Felker:

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

Right, but if libc code traps without violating preconditions, that's
generally a bug.  And if you violate preconditions, than *that* already
triggers undefined behavior, and not the trap later on.  (For example,
the compiler uses the knowledge of well-known functions and optimizes
accordingly.)

Thanks,
Florian