[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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