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

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

[Alejandro Colomar]

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

Hi,

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.

$ grepc gcvt .
./include/stdlib.h:char *gcvt(double, int, char *);
./src/stdlib/gcvt.c:char *gcvt(double x, int n, char *b)
{
	sprintf(b, "%.*g", n, x);
	return b;
}

Have a lovely day!
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

[Leah Neukirchen]

Alejandro Colomar <alx@kernel.org> writes:

> Hi,
>
> 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

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

I recommend not putting application logic into signal handlers.

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

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

[Alejandro Colomar]

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

Hi Leah,

On Wed, May 01, 2024 at 05:19:25PM +0200, Leah Neukirchen wrote:
> Alejandro Colomar <alx@kernel.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/>

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

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

[Rich Felker]

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 <alx@kernel.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!

It doesn't matter either way because musl's s[n]printf is AS-safe.

Rich

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

[Alejandro Colomar]

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

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!

Have a lovely day!
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

[Rich Felker]

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

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