* [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe @ 2024-05-01 15:09 Alejandro Colomar 2024-05-01 15:19 ` Leah Neukirchen 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-01 15:09 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 15:09 [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe Alejandro Colomar @ 2024-05-01 15:19 ` Leah Neukirchen 2024-05-01 15:38 ` Alejandro Colomar 0 siblings, 1 reply; 10+ messages in thread From: Leah Neukirchen @ 2024-05-01 15:19 UTC (permalink / raw) To: Alejandro Colomar; +Cc: musl 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/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 15:19 ` Leah Neukirchen @ 2024-05-01 15:38 ` Alejandro Colomar 2024-05-01 17:21 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-01 15:38 UTC (permalink / raw) To: Leah Neukirchen; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 15:38 ` Alejandro Colomar @ 2024-05-01 17:21 ` Rich Felker 2024-05-01 19:55 ` Alejandro Colomar 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2024-05-01 17:21 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Leah Neukirchen, musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 17:21 ` Rich Felker @ 2024-05-01 19:55 ` Alejandro Colomar 2024-05-01 23:04 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-01 19:55 UTC (permalink / raw) To: Rich Felker; +Cc: Leah Neukirchen, musl [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 19:55 ` Alejandro Colomar @ 2024-05-01 23:04 ` Rich Felker 2024-05-01 23:45 ` Alejandro Colomar 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2024-05-01 23:04 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Leah Neukirchen, musl 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 23:04 ` Rich Felker @ 2024-05-01 23:45 ` Alejandro Colomar 2024-05-01 23:57 ` Thorsten Glaser 2024-05-02 0:01 ` Alejandro Colomar 0 siblings, 2 replies; 10+ messages in thread From: Alejandro Colomar @ 2024-05-01 23:45 UTC (permalink / raw) To: Rich Felker; +Cc: Leah Neukirchen, musl, libc-alpha, Richard Russon [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 23:45 ` Alejandro Colomar @ 2024-05-01 23:57 ` Thorsten Glaser 2024-05-02 0:01 ` Alejandro Colomar 1 sibling, 0 replies; 10+ messages in thread From: Thorsten Glaser @ 2024-05-01 23:57 UTC (permalink / raw) To: musl; +Cc: Rich Felker, Leah Neukirchen, libc-alpha, Richard Russon 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-01 23:45 ` Alejandro Colomar 2024-05-01 23:57 ` Thorsten Glaser @ 2024-05-02 0:01 ` Alejandro Colomar 2024-05-02 20:34 ` Joseph Myers 1 sibling, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-02 0:01 UTC (permalink / raw) To: Rich Felker; +Cc: Leah Neukirchen, musl, libc-alpha, Richard Russon [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe 2024-05-02 0:01 ` Alejandro Colomar @ 2024-05-02 20:34 ` Joseph Myers 0 siblings, 0 replies; 10+ messages in thread From: Joseph Myers @ 2024-05-02 20:34 UTC (permalink / raw) To: Alejandro Colomar Cc: Rich Felker, Leah Neukirchen, musl, libc-alpha, Richard Russon 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-05-02 21:35 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-05-01 15:09 [musl] gcvt(3) should be MT-Safe, AS-Safe, AC-Safe Alejandro Colomar 2024-05-01 15:19 ` Leah Neukirchen 2024-05-01 15:38 ` Alejandro Colomar 2024-05-01 17:21 ` Rich Felker 2024-05-01 19:55 ` Alejandro Colomar 2024-05-01 23:04 ` Rich Felker 2024-05-01 23:45 ` Alejandro Colomar 2024-05-01 23:57 ` Thorsten Glaser 2024-05-02 0:01 ` Alejandro Colomar 2024-05-02 20:34 ` Joseph Myers
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).