[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d31e629b-2455-3816-85a5-dfd9a44c65b@redhat.com>
Date: Thu, 2 May 2024 20:34:37 +0000 (UTC)
From: Joseph Myers <josmyers@...hat.com>
To: Alejandro Colomar <alx@...nel.org>
cc: Rich Felker <dalias@...c.org>, 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
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@...hat.com
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.
