This is the mail archive of the
mailing list for the newlib project.
Re: sprintf() heap usage
- From: Federico Terraneo <fede dot tft at hotmail dot it>
- To: newlib at sourceware dot org
- Date: Tue, 16 Jul 2013 20:07:58 +0200
- Subject: Re: sprintf() heap usage
- References: <CA+gZxsO8PrqwaTU-xMJ1QrOvz3otf_uVt2ap-wGtdKj7niX7GQ at mail dot gmail dot com> <51E56435 dot 60408 at redhat dot com> <CA+gZxsOL9xuOn2Fi7t=pRPP3oqmj8B0X2RQeqOSyg-Kn9aJUJQ at mail dot gmail dot com>
-----BEGIN PGP SIGNED MESSAGE-----
On 07/16/2013 05:23 PM, Vasili Galka wrote:
> I see. Thank you!
> On Tue, Jul 16, 2013 at 6:18 PM, Eric Blake <email@example.com>
>> On 07/16/2013 03:39 AM, Vasili Galka wrote:
>>> I've been surprised to discover that using sprintf() leads to
>>> requirement of sbrk(). Can anyone please explain me why? For
>>> gods sake, the function already has output buffer provided.
>>> The lifetime of the function is well defined and it has stack.
>>> Why would it require heap!?
>> Computation of %g and friends can require allocation in order to
>> safely convert a power-of-two floating-point number into a
>> power-of-10 string representation (particularly for numbers on
>> the extreme small end, like 1e-300). Even if the final
>> representation fits in the buffer passed into snprintf, the
>> intermediate conversion steps require more bytes than can be
>> safely allocated within a single page of the stack, and as
>> newlib cannot assume a large stack size, it is easier to
>> implement the conversion process using the heap.
You may want to try siprintf(). It's a newlib-specific function that
doesn't support floating point numbers, but has a reduced code size.
Now, I haven't actually checked that it doesn't use the heap (as I
tend to use malloc also in deeply embedded systems), but it might be
worth a try.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----