[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZjLUHRQqEPo1Urb_@debian>
Date: Thu, 2 May 2024 01:45:27 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.org>
Cc: Leah Neukirchen <leah@...u.org>, musl@...ts.openwall.com,
libc-alpha@...rceware.org, Richard Russon <rich@...tcap.org>
Subject: Re: gcvt(3) should be MT-Safe, AS-Safe, AC-Safe
[CC += libc-alpha (glibc), Richard]
Hi Rich Felker,
On Wed, May 01, 2024 at 07:04:38PM -0400, Rich Felker wrote:
> 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)
I realize that dprintf(3) is not documented in the ATTRIBUTES section of
its manual page. POSIX doesn't seem to document AS safety of it (or of
most functions FWIW). glibc's manual doesn't seem to document
dprintf(3) at all. I guess I should fix that.
The BSDs don't seem to document it as being AS-safe either. NetBSD
mentions the existence of snprintf_ss(3), but nothing about dprintf(3).
FreeBSD is silent. OpenBSD is silent too.
I've CCed glibc so that they confirm that this is MT-safe + AS-safe on
glibc. I guess if the original design was to have it AS-safe, we can
report bugs to the BSDs so that they document their AS safety status,
and that they make the function AS-safe if it isn't already.
Also, having dprintf(3) documented as AS-safe by design would be a great
standard solution for my original interest, which was finding a libc
portable AS-safe replacement for printf(3). I could just
dprintf(STDOUT_FILENO, ...)
and avoid any hand-written wrappers around write(1).
> and even fprintf is
> under the condition that you're not interrupting code accessing the
> same FILE you pass to it.
>
> Rich
Have a lovely night!
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.
