Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe

[Rich Felker <dalias@libc.org>]

On Wed, May 01, 2024 at 05:38:03PM +0200, Alejandro Colomar wrote:
> Hi Leah,
> 
> On Wed, May 01, 2024 at 05:19:25PM +0200, Leah Neukirchen wrote:
> > Alejandro Colomar <alx@kernel.org> writes:
> > > glibc's gcvt(1) is documented to be MT-Safe | AS-Safe | AC-Safe.
> > > <https://sourceware.org/glibc/manual/latest/html_mono/libc.html#index-gcvt>
> > > It's an interesting function to be called from a signal handler, where
> > > snprintf(3) is not available.
> > >
> > > But musl implements it as a call to sprintf(3); that doesn't seem safe.
> > 
> > POSIX 2001 says:
> > https://pubs.opengroup.org/onlinepubs/009695399/functions/gcvt.html
> 
> It seems POSIX doesn't require it to be safe.
> 
> However, it is _useful_ to make it safe as an extension to POSIX.
> 
> Solaris 11 documents it as MT-Level Safel; they don't list it as
> "Async-Signal-Safe", though.  :/
> 
> > > These functions need not be reentrant. A function that is not
> > > required to be reentrant is not required to be thread-safe.
> > 
> > POSIX 2008 removed the whole function.
> 
> Yup.  But that doesn't mean it's a useless function.
> 
> > I recommend not putting application logic into signal handlers.
> 
> I was looking at this:
> <https://gitlab.com/muttmua/mutt/-/blob/master/signal.c?ref_type=heads#L95>
> which implements something like gcvt(3) (but moch more basic) to report
> an error, and was wondering if anything from libc would work.  gcvt(3)
> is not portable, so it's not usable there, but it was interesting,
> nevertheless.
> 
> Have a lovely day!

It doesn't matter either way because musl's s[n]printf is AS-safe.

Rich