[Ffmpeg-devel] [PATCH] Correct inttypes.h emulation for Visual Studio

[Måns Rullgård]

Stefan Heinzmann said:
> --- M?ns Rullg?rd <mru at inprovide.com> wrote:
>
>> None of the direct replies to the patch can be called flames.  The
>> patch was rejected, and a clear reason for the rejection was stated.
>
> Yes, and the reason is open for debate. Particularly since it
> is plainly obvious that behind the given technical reason
> there's another non-technical one that's driving it.

The reasons for me rejecting that patch are purely technical.  Having
workarounds for broken systems in the code is a maintenance nightmare,
especially when you do no use the system in question.  Requiring minimal
support for a 7-year old standard is not unreasonable.  Not providing
said support in a compiler is unreasonable.  End of story.

>> >> > I identify this as active hate, not as "not proactive support".
>> >> I suggest you refer back to your English as a Second (or Third?)
>> >> Language textbook because your definition is waaaaaay off. And it's also
>> >> offensive, to boot.
>> > Yes, my second is C++. And English is third. :)
>> > But I'm sure I say exactly what I want in here.
>>
>> In that case, please go away now.  We don't want to talk
>> with you.
>
> Who is 'we'? The list? The orthodox ffmpeg purists as opposed
> to the M$-heretics? Or pluralis majestatis?

'We' is myself and other ffmpeg developers.

>> > Are you agree to adding MS-specific inttypes as separate header to
>> > FFMpeg source tree?
>>
>> No.  The error is not in FFmpeg, so it can't be corrected
>> there.
>
> The 'error' as you call it can indeed not be 'corrected' in
> ffmpeg. A workaround however can be provided in ffmpeg, and
> this is what the patch is about. Providing workarounds for
> deficiencies in the 'environment' is common practice for
> libraries even when they're strictly limited to *nix. This
> for example is one reason why such hideously complex tools
> like autoconf/automake exist, and their existence has got
> nothing to do with M$.

I am fully aware that the patch is adding a workaround for a broken compiler.
What we have repeatedly stated is that we do not want such a workaround.  If
you wish to use MSVC, adding your own inttypes.h should take no more than 2
minutes, and will solve the problem not only with ffmpeg, but with every
package that uses those typedefs.

> Tools and environments deficiencies are a sad fact of life
> which can not always be dealt with in the 'right' way.

But this one can be dealt with the right way.

> Workarounds are a compromise, they're sometimes ugly, but
> they're a practical solution to a practical problem, and
> they're much better than banging your head against a wall.

As others have already explained, workarounds should be done as close to
the problem as possible.  In this case the problem is not in ffmpeg, it's
in the MSVC headers.  That is where the fix must go too.  You're the one
banging your head against a wall, not me.

> MSVC and Windows will not go away anytime soon and no amount

I'm afraid you're right.  That still doesn't impose even the slightest
requirement on us to support it.

> of bullyish and arrogant behaviour will change this. There
> are many who have no real choice but using and/or supporting
> Windows, short of quitting their job and looking for
> something else. Treating them like second class people will
> not likely convert them to your religion.

If my system is deficient in some way, I fix it.  Why can't the windows users
do the same?

> I understand perfectly well that you have no personal
> interest in proactively supporting an OS (or with it its
> supplier) you don't like, and I have to accept this. But
> applying a patch you haven't written yourself isn't what I
> would call proactive support.

It's not as simple as applying a patch from somebody else.  If a workaround
is applied, every future change must be verified not to break it.  This is
cumbersome in general, and impossible for MSVC related hacks, since few, if
any, ffmpeg developers use it.

> In my opinion it is merely acknowledging that a workaround is needed for a
> popular platform.

I don't care about what's popular, and we already know it's broken.  Now we'd
appreciate if the users of said platform acknowledged it being broken.

> The way you act here is more like proactively pissing off
> MSVC users, and that is not pragmatic, it is ideologic.
> Hiding this behind the technical issue of C99 compliance is
> not particularly convincing IMHO. It simply seems dishonest,
> and that's why these 'flame wars' emerge every now and then.
> They're not being imposed on you by retarded M$-lovers, it is
> your own behaviour that is provoking them.

It's the MS lovers that keep sending us these unwanted patches, and it was
(one of) them who started this flame war.  I can't see that I, or any other
ffmpeg developer, did anything to provoke them.

-- 
M?ns Rullg?rd
mru at inprovide.com