This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: sprintf without realloc?
- From: "Schwarz, Konrad" <konrad dot schwarz at siemens dot com>
- To: "Darin Johnson" <darin at usa dot net>, "Matt Gessner" <mgessner at Avidyne dot com>, <newlib at sourceware dot org>
- Date: Tue, 26 Sep 2006 08:48:56 +0200
- Subject: RE: sprintf without realloc?
> -----Original Message-----
> From: newlib-owner@sourceware.org
> [mailto:newlib-owner@sourceware.org] On Behalf Of Darin Johnson
> Sent: Monday, September 25, 2006 10:50 PM
> To: Matt Gessner; newlib@sourceware.org
> Subject: RE: sprintf without realloc?
>
> >My original post wasn't clear; I'm prevented from using any kind of
> >*alloc based function that dynamically manages memory.
>
> Hmm, from a quick look at the code, malloc() is really only
> needed to support the "%S" and "%ls" formats (wide character strings).
I suspect that it is also used to allocate the buffer used in fully- and
line-buffered mode, and, at least in some cases, to ensure that space is
available for the FILE object.
You can combat the first problem by using a statically allocated buffer
with setvbuf(), and, at least on classical <stdio> implementations, by
ensuring that the number of FILEs you have open at the same time is
below a fixed limit, such as 20.
However, malloc() will still be linked to your code, so you will still
have to add a dummy.
If your coding rules prohibit you from having malloc() linked to your
code at all, then either you will have to stop using stdio routines, or
modifiy your (somewhat short sighted) coding rules.
Note that the VxWorks operating system has a printf() implementation
that does not buffer, and therefore does not use malloc(). But
fprintf() does, of course.
Regards,
Konrad Schwarz