From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 27058212C8 for ; Wed, 1 May 2024 19:21:31 +0200 (CEST) Received: (qmail 18241 invoked by uid 550); 1 May 2024 17:21:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18191 invoked from network); 1 May 2024 17:21:26 -0000 Date: Wed, 1 May 2024 13:21:39 -0400 From: Rich Felker To: Alejandro Colomar Cc: Leah Neukirchen , musl@lists.openwall.com Message-ID: <20240501172138.GC10433@brightrain.aerifal.cx> References: <87jzkdr24i.fsf@vuxu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 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 writes: > > > glibc's gcvt(1) is documented to be MT-Safe | AS-Safe | AC-Safe. > > > > > > 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: > > 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