[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZjJh4cvtKq7xCc2z@debian>
Date: Wed, 1 May 2024 17:38:03 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Leah Neukirchen <leah@...u.org>
Cc: musl@...ts.openwall.com
Subject: Re: gcvt(3) should be MT-Safe, AS-Safe, AC-Safe
Hi Leah,
On Wed, May 01, 2024 at 05:19:25PM +0200, Leah Neukirchen wrote:
> Alejandro Colomar <alx@...nel.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!
Alex
--
<https://www.alejandro-colomar.es/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
