https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
--- Comment #14 from dave.anglin at bell dot net --- On 2018-09-04 10:16 AM, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 > > --- Comment #13 from dave.anglin at bell dot net --- > On 2018-09-04 9:48 AM, redi at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 >> >> --- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> --- >> (In reply to dave.anglin from comment #11) >>> JAGaf47646: with small buffer vsnprintf always returns -1 >> Aha, that is probably it. We pass 0 as the size, which is supposed to make >> vsnprintf tell you how many bytes it would have written (as that's how we >> find >> out the required length). >> >> It's curious that it printed "returned 4, errno = 0" when you tested it >> though. >> Maybe GCC optimized the call and didn't use the OS function. >> >> Does it return -1 if you use -fno-builtin-vsnprintf ? > No. I checked .s file and GCC isn't optimizing the call. It returns -1 > when passed a nonzero size > that is too small. > > Passing 4 causes it to return -1: > using vsnprintf > returned -1, errno = 0 > > Passing 5 is okay: > using vsnprintf > returned 4, errno = 0 > > Maybe it's returning an incorrect length when passed 0 in some locales? No, it uses the buffer when passed a a size of 0: https://stackoverflow.com/questions/619497/heap-corruption-in-hp-ux
