[FFmpeg-devel] [PATCH] configure: Enable MinGW-w64's implementation of vsnprintf and pals

[Reimar Döffinger]

Derek Buitenhuis <derek.buitenhuis at gmail.com> wrote:

>On 2013-05-17 2:14 AM, Reimar Döffinger wrote:
>> Isn't that make my point all the stronger and an extra good reason to
>> _not_ use two implementations?
>> If anything this would be an argument to use a wrapper even on
>> Linux/Unix to make sure we do not use %zu by accident, since it's
>> not going to work on some systems after all.
>
>We do use %zu, and (certain) people seem dead set against removing its
>use, since it is the "most correct" thing to use for size_t prints.

Is that still the case? Because I find it very hard to argue that broken code would be "most correct".
In addition using some macro would still allow using zu on Linux.

>As it stands MSVC and old MinGW are the only platforms which do not
>have
>a proper vsnprintf implementation. Also, our implementation is very
>Windows-specific -- it won't work on anything else, and it's silly to
>use it anywhere else. Thirdly, the usual "system implementations are
>likely more optimzied" argument.

I very much hope performance isn't relevant, otherwise using printf is a mistake in the first place.

>IMHO, the "most correct" thing to do is only provide it for platforms
>that
>need it. You don't see us providing llrint() on platforms that have it,
>do
>you?

I know of no issues where the platform or our re-implementation requires special care in how we use it.
It just seems to me that special-casing newer mingw is additional effort that at best hides bugs in our code that still will affect some users.
And how easy will it be to find out which printf variant was used by the ffmpeg some user used in a bug report?
I admit I argued far longer than I care about it (and Windows in general), but my gut tells me it's a rather bad idea.