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

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

[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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Thorsten Glaser]

Alejandro Colomar dixit:

>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.

Huh? https://man.openbsd.org/signal.3 not enough?

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

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

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

On Thu, May 02, 2024 at 01:45:27AM +0200, Alejandro Colomar wrote:
> [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've been digging into the archives, and found it:
<https://inbox.sourceware.org/libc-alpha/20130925180327.0351F2C097@topped-with-meat.com/>

But then it seems that, at least in 2013, it wasn't AS-safe:
<https://inbox.sourceware.org/libc-alpha/20130925212954.GQ20515@brightrain.aerifal.cx/>

It would be interesting to know the status as of today (if I have to
guess, I'd bet it's unsafe), and also if there could be any guarantees
that at least a subset of dprintf(3) was guaranteed to be AS-safe (e.g.,
ignoring '$', wide-char, ...).

> 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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Joseph Myers]

On Thu, 2 May 2024, Alejandro Colomar wrote:

> > > dprintf is also AS-safe (as intended by its creator; this was
> > > discussed on the glibc list a few years back)
> 
> I've been digging into the archives, and found it:
> <https://inbox.sourceware.org/libc-alpha/20130925180327.0351F2C097@topped-with-meat.com/>
> 
> But then it seems that, at least in 2013, it wasn't AS-safe:
> <https://inbox.sourceware.org/libc-alpha/20130925212954.GQ20515@brightrain.aerifal.cx/>
> 
> It would be interesting to know the status as of today (if I have to
> guess, I'd bet it's unsafe), and also if there could be any guarantees
> that at least a subset of dprintf(3) was guaranteed to be AS-safe (e.g.,
> ignoring '$', wide-char, ...).

Floating-point printf still uses malloc (with essentially unbounded size, 
although logically it should be possible to bound the size since no 
supported floating-point format can have more than 4933 decimal digits 
before the decimal point or 16494 after it - anything outside that range 
must be zero and so shouldn't need memory allocation); see bug 21127.  
There may also be other places where malloc is called, beyond the ones for 
temporary storage of formatted output.  The commit message for commit 
6caddd34bd7ffb5ac4f36c8e036eee100c2cc535 (which removed some unnecessary 
allocation logic) lists various relevant bugs in more detail.

-- 
Joseph S. Myers
josmyers@redhat.com