Re: [musl] [PATCH 2/2] man/man2/fork.2: Document glibc and musl relaxed fork->exec AS requirements

[Gabriel Ravier <gabravier@gmail.com>]

On 10/2/26 8:50 AM, Trevor Gross wrote:
> On Fri Sep 25, 2026 at 2:54 PM CDT, Florian Weimer wrote:
>> * Rich Felker:
>>
>>>> +On glibc and musl libc, this is relaxed;
>>>> +it is safe to call non-async-signal-safe functions in the time between
>>>> +.BR fork ()
>>>> +and
>>>> +.BR exec ()
>>>> +\&.
>>> While glibc has taken measures to make this mostly work, especially
>>> malloc-after-fork, I don't think glibc has an intentional model for
>>> ensuring that arbitrary libc functions work right in the child of a
>>> multithreaded fork. Before accepting such a man page patch, we should
>>> at least get an official position from glibc on whether they claim
>>> this property or at least aim for it.
>> Far from everything in glibc is fork-protected, so the statement is not
>> true today as far as glibc is concerned.  We try to maintain
>> compatibility with existing application requirements, but the precise
>> goals have not been written down.
> Would the following be more accurate?
>
>      On glibc and musl libc, this is relaxed. With musl environments, it
>      is safe to call non-async-signal-safe functions in the time between
>      fork() and exec(). With glibc environments, some functions that are
>      not AS-safe may be called between fork() and exec() may be safe to
>      call; however, there is no exact list maintained.

At the very least, it shouldn't duplicate the "may be safe to call" 
clause :p

>
> Open to better wording as well, I'm not sure sure how best to express
> the glibc case - if that's worth it at all.
>
> Rich, is this reasonable to document for musl? It is a rather helpful
> property even if not portable, but I'm not sure whether it is more of an
> implementation detail for improved compatibility vs. something musl is
> comfortable with users relying on.
>
> - Trevor