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
>