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: asprintf bugs


Jeff Johnston <jjohnstn <at> redhat.com> writes:

> 
> Thanks for the analysis Eric.  Patch checked in.
> 
> Regarding minimizing the asprintf default buffer size, yes, it would be 
> worth pursuing.  I made up a trial patch.  It simply checks for __SMBF 
> inside __smakebuf.  If already set, this implies that the asprintf 
> family is using the routine for the first time.  Try it out and let me 
> know what you think.
> 

Looks correct to me.  By lowering the default initial buffer size, it means 
that a 1024 byte result from asprintf will call realloc up to 7 times, but my 
gut feeling is that typical usage of asprintf does not often deal with strings 
this long (otherwise the off-by-one error probably would have been caught much 
sooner).  And your patch still guarantees that asprintf(&s,"") still allocates 
(something to make sure of, since that execution path does not go through 
__sfvwrite_r for a realloc but asprintf must always allocate).

My original thoughts had been along the lines of making __smakebuf skip 
allocation altogether if __SSTR, but then asprintf would also have to be 
modified to check for f._w of 0 and do a zalloc(1) in that case; not to mention 
that growth from 0 to 64 bytes requires up to 9 additional realloc calls.  64 
is a good default, since in some malloc implementations (at least in glibc 
malloc) it is the largest "small" chunk of memory, anything larger switches 
over to "large" chunk handling.  So I like your patch better than my original 
idea.

-- 
Eric Blake



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