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

["Trevor Gross" <tg@trevorgross.com>]

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.

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