"Ronald S. Bultje" <[email protected]> writes:
> Hi,
>
> On Wed, Aug 1, 2012 at 11:58 AM, Måns Rullgård <[email protected]> wrote:
>> Luca Barbato <[email protected]> writes:
>>
>>> +#if !HAVE_SNPRINTF
>>> +#ifdef _MSC_VER
>>> +#define vsnprintf _vsnprintf
>>> +#endif
>>> +
>>> +int snprintf(char *buffer, size_t bufsize, const char *fmt, ...)
>>> +{
>>> + va_list ap;
>>> + int ret;
>>> +
>>> + if ((int)bufsize <= 0) return -1;
If bufsize > INT_MAX, that cast has unspecified behaviour.
>>> + va_start(ap, fmt);
>>> + ret = vsnprintf(buffer, bufsize-1, fmt, ap);
>>> + if (ret < 0) {
>>> + buffer[bufsize - 1] = '\0';
>>> + ret = bufsize - 1;
>>> + }
This fails to null-terminate the output if the formatted length is
exactly bufsize-1.
>>> + va_end(ap);
>>> + return ret;
>>> +}
>>
>> This assumes that any system without snprintf will have vsnprintf with
>> microsoft semantics. That's a pretty bold assumption.
>
> Well, it is harmless in the sense that non-MS vsnprintf() never
> returns <0, right?
Standard vsnprintf() returns a negative value if an error occurred, in
which case the code above leaves the contents of the buffer undefined.
The microsoft manual does not say what the functions do on error.
God knows what some random vsnprintf() on a system without snprintf()
might do, such a system by definition being non-standard.
> But we can put this under #ifdef _MSC_VER if you prefer that.
>
>>> +#if !HAVE_SNPRINTF
>>> +int ff_snprintf(char *buffer, size_t bufsize, const char *fmt, ...);
>>> +#define snprintf(...) ff_snprintf(__VA_ARGS__)
>>> +#endif
>>
>> WTF?
>
> The idea here (quoting Luca) is to not cause symbol collisions with
> other libs or apps providing their own snprintf replacement. Clearly
> the above implementation should have been called ff_snprintf() also,
> or maybe actually avpriv_snprintf() (as suggested by Alex), since
> lavf/lavfi/lavc/lavr/sws may want to use it also. But the idea is to
> prevent symbol collisions.
I know what the idea is. The code does something else entirely.
--
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
