This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]