[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240501230438.GD10433@brightrain.aerifal.cx>
Date: Wed, 1 May 2024 19:04:38 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: Leah Neukirchen <leah@...u.org>, musl@...ts.openwall.com
Subject: Re: gcvt(3) should be MT-Safe, AS-Safe, AC-Safe
On Wed, May 01, 2024 at 09:55:10PM +0200, Alejandro Colomar wrote:
> On Wed, May 01, 2024 at 01:21:39PM -0400, Rich Felker wrote:
> > It doesn't matter either way because musl's s[n]printf is AS-safe.
>
> Hmm; interesting. Thanks!
Yes, it's a pure function (aside from fenv, errno for %m, and possibly
LC_NUMERIC in the future) and has no reason to do anything AS-unsafe
unless you implement it with dynamic allocation, in which case you
have unforced failure cases which are very low QoI.
musl's printf core also has very low stack usage suitable for AS use,
at least in principle. LLVM and possibly modern GCC like to
inline-and-lift the slightly-large (IIRC something like 6-8k on
ld80/IEEE-quad archs, 2k on ld64 archs) floating point workspace to be
allocated unconditionally, but if you can suppress that, it should
only need a few hundred bytes of stack.
dprintf is also AS-safe (as intended by its creator; this was
discussed on the glibc list a few years back) and even fprintf is
under the condition that you're not interrupting code accessing the
same FILE you pass to it.
Rich
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.
