Re: StringBuffer overflow
David Hakim <dhakim-Gkm/TONP9n1Wk0Htik3J/[email protected]> Sun, 6 Jul 2003 17:12:59 -0400
| Newsgroups | gmane.comp.lang.moto.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sunday, July 6, 2003, at 05:51 PM, Stefano Corsi wrote: > We coud exploit this behaviour of vsnprintf (valid from glibc 2.1): > > These functions return the number of characters printed > (not including the trailing `\0' used to end output to > strings). snprintf and vsnprintf do not write more than > size bytes (including the trailing '\0'), and return -1 if > --> the output was truncated due to this limit. (Thus until > --> glibc 2.0.6. Since glibc 2.1 these functions follow the > --> C99 standard and return the number of characters (exclud- > --> ing the trailing '\0') which would have been written to > --> the final string if enough space had been available.) > > So it appears that if we call vsnprintf once and it returns a number > that is > larger than BUF_PRINTF_MAXLEN, then we can buf_grow() to the needed > size, > then call vsnprintf again this time with the right values. > This if we assume that we stay confortable with this semantics of > vsnprintf. > Look at this, also: > > Concerning the return value of snprintf, the SUSv2 and the > C99 standard contradict each other: when snprintf is > called with size=0 then SUSv2 stipulates an unspecified > return value less than 1, while C99 allows str to be NULL > in this case, and gives the return value (as always) as > the number of characters that would have been written in > case the output string has been large enough. > > What do you think? > That sounds like a real good plan ... could you try it with an initial max of 4096 bytes and verify that the gccbufferoverflow test passes with the algorithm you sketched out ? -Dave > Stefano >