Uoti Urpala <uoti.urp...@pp1.inet.fi> writes:
> On Wed, 2012-08-01 at 21:34 +0100, Måns Rullgård wrote:
>> Uoti Urpala <uoti.urp...@pp1.inet.fi> writes:
>> >> + ret = vsnprintf(buffer, bufsize-1, fmt, ap);
>> >
>> > IIRC MSVC (or the C library) does not support all standard format
>> > modifiers, so unless this vsnprintf comes from elsewhere, you need more
>> > to get fully working printf formatting.
>> >
>> > I'm not sure if this is working in current MinGW-compiled Libav either -
>> > you need to set __USE_MINGW_ANSI_STDIO at least; the problem cases
>> > probably occur rarely enough that problems may go unnoticed.
>> >
>> >> + if (ret < 0) {
>> >> + buffer[bufsize - 1] = '\0';
>> >> + ret = bufsize - 1;
>> >
>> > Wrong return value. It's supposed to be the number of bytes the output
>> > would take without restriction. The following pattern is supposed to
>> > work:
>> >
>> > int r = snprintf(NULL, 0, ...);
>> > if (r < 0) return -1;
>> > char *p = malloc(r + 1);
>> > snprintf(p, r, ...);
>>
>> It is not possible to get those semantics using the regular Windows
>> functions.
>
> Of course it is, with enough workarounds (this is already an attempt at
> a workaround, getting it right would just require more code). I think
> there are rather obvious ways to fix both issues (besides the most
> obvious but more work-requiring alternative of writing correct snprintf
> from scratch): rewrite the format string with different modifiers for
> the first, try printing the string into temporary storage and double its
> size until you succeed for the second.
Of course writing your own, correct snprintf() is possible. You are
then, however, not using the Windows-provided functions.
Writing into temp buffers is not exactly equivalent to the standard
behaviour. The standard function can succeed in calculating the size
that *would* be required even actually allocating it fails.
If you insist on arguing, I politely request that you at least be right.
--
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
