This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] signal-safe fprintf?
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: libc-alpha at sourceware dot org, ahh at google dot com
- Date: Thu, 7 Mar 2013 11:40:58 +0530
- Subject: Re: [RFC] signal-safe fprintf?
- References: <ye6qboax76qu.fsf@elbrus2.mtv.corp.google.com>
On 6 March 2013 05:13, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> It would be *really* convenent if snprintf could be split into the
> "regular" snprintf, and a snprintf_nomalloc(). The latter would return
> ENOMEM if malloc was actually required.
snprintf could use mmap directly, which is slow but at least does not
fail when there is memory available. The alloca cutoff threshold is
currently 64K, so the mmap requests would be a minimum of 16 pages,
with the worst case for space wastage being about 6.25% of the request
(65537 bytes requested and given 69632). That way there's no need for
such a special case function.
We could also have a magic environment variable that allows the code
to use malloc instead, reverting to old behaviour ;)
Siddhesh
--
http://siddhesh.in