This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: SIGINT, longjmp, getaddrinfo
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Michael Kerrisk <mtk dot manpages at gmail dot com>
- Cc: Hal Murray <hmurray at megapathdsl dot net>, libc-help <libc-help at sourceware dot org>
- Date: Tue, 16 Feb 2016 12:51:03 -0500
- Subject: Re: SIGINT, longjmp, getaddrinfo
- Authentication-results: sourceware.org; auth=none
- References: <carlos at systemhalted dot org> <CAE2sS1jyUtbcZmyX234xJ=7R44=Mt+1tMUh+yJ32OiHt1ro7QA at mail dot gmail dot com> <20160216031136 dot 4E51E406057 at ip-64-139-1-69 dot sjc dot megapath dot net> <CALxWeYo2Briq=2vVQVa0UaKMRQJtbHSb+un-Jgdksu4v0yqRmQ at mail dot gmail dot com>
On Tue, Feb 16, 2016 at 10:00 AM, Michael Kerrisk
<mtk.manpages@gmail.com> wrote:
>> I'm still surprised that there isn't some web page that documents and
>> discusses this whole area.
>
> <Blush> Well, I know there's a book that covers it...
>
> And now I've added this text to the completely revamped setjmp(2) man page[1]:
>
> POSIX.1-2008 Technical Corrigendum 2 adds longjmp() and sigâ
> longjmp() to the list of async-signal-safe functions. However,
> the standard recommends avoiding the use of these functions from
> signal handlers and goes on to point out that if these functions
> are called from a signal handler that interrupted a call to a
> non-async-signal-safe function (or some equivalent, such as the
> steps equivalent to exit(3) that occur upon a return from the
> initial call to main()), the behavior is undefined if the program
> subsequently makes a call to a non-async-signal-safe. The only
> way of avoiding undefined behavior is to ensure one of the folâ
> lowing:
>
> * After long jumping from the signal handler, the program does
> not call any non-async-signal-safe functions and does not
> return from the initial call to main().
>
> * Any signal whose handler performs a long jump must be blocked
> during every call to a non-async-signal-safe function and no
> non-async-signal-safe functions are called after returning
> from the initial call to main().
>
> Hopefully that covers everyone's concerns.
Very well worded. Thanks for the update.
Cheers,
Carlos.