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

[Måns Rullgård]

Could you please fix the line-wrapping in your mailer, or switch to a mailer
that gets it right?  Fixing it manually when replying to you is getting tedious.

Stefan Heinzmann said:
> --- M?ns Rullg?rd <mru at inprovide.com> wrote:
>
>> 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.
>
> It would help if you didn't present as a fact what is in
> reality you personal opinion. Windows or MSVC is only broken
> according to *your* criteria, not everybody's.

It is certainly not my criteria.  We're comparing compilers against the
document titled ISO/IEC 9899:1999 Programming languages ? C, aka C99.  I
had nothing to do with the authoring of this text.  I do not even know any
of those people who did.

> It is very
> easy to come up with any number of technical reasons against
> any platform you want to declare broken. Whether supporting
> C99 is unreasonable or not is depending on a point of view,
> and hence isn't a fact either.

If you are trying to produce a C compiler today, opting not to support
the most basic features of C99 does seem quite unreasonable.  It's akin
to writing a web browser that only supports HTML 2.0.  (Oh, I forgot...
MS do that as well.)

> The same holds for what amount
> of support can be considered 'minimal'. gcc's support for C99
> goes further than MSVC's, for sure, but isn't complete
> either. To presume that its level of support for C99 is
> 'reasonable' is therefore again a matter of opinion.

I'm not presuming anything here.  GCC happens to be one of many compilers
that do have an adequate level of C99 support.  Please take note that we
do not support building with gcc1 on a libc4 based system either.

> That does not make your opinion wrong, but it separates it
> from a fact, and it prevents your decisions from being purely
> based on technical reasons. Your reasons are no more or less
> technical than those put forward by the M$-users here.

The only reasons I've seen put forward so far *for* the inclusion of the
proposed hack is sheer laziness on the part of the MSVC users.  They want
us to jump through hoops to save them 2 minutes of work.  I'm sorry, but
that's not likely to happen.

> I'm not demanding that you subscribe to my point of view, but
> insisting on your point of view being the right one is
> patronizing, and pretending that it is technical and purely
> based on fact is not credible.

How can it be a matter of point of view whether MSVC has a certain typedef?
It's quite indisputable that it's lacking a few that we happen to need.

>> >> >> > 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.
>
> So what is the point in one group of ffmpeg developers not
> wanting to talk with another group of ffmpeg developers?

So far all ffmpeg developers who have spoken on this issue have agreed.  Those
disagreeing are whinging MSVC users who have never contributed a single line of
code.

>> >> > 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.
>
> But it was there before, through EMULATE_INTTYPES, so what is
> so unbearable or nightmareish about it that it had to be
> removed?

It was not only difficult to maintain, but also potentially incorrect.  Hence
we removed it.

>> 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 does not even *want* to be C99 compliant, so the problem
> isn't with its headers. They are ok for what they aspire to
> be. The problem is what level of C99 compliance is to be
> required from C compilers which are used for projects using
> ffmpeg (not for those used to compile ffmpeg). And that is
> again largely not a technical, but a strategic question. It
> is a function of the platforms you want to support. End of
> story ;-)

OK, now you admit to trying to use ffmpeg headers with a compiler for a
different language than said headers were written in.  For your information,
those headers do not work with compilers for Pascal, Fortran, ADA, or numerous
other languages either.

>> > 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.
>
> On that level there aren't any requirements at all for
> projects conducted by volunteers. That's why I don't talk
> about requirements. I'm trying to be pragmatic, that's all,
> and I'd prefer if others were pragmatic, too.

The applicable dictionary definition of the word pragmatic is
"practical as opposed to idealistic" (Merriam-Webster).  Your
stance hardly strikes me as fitting this description.

>> > 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?
>
> They might not agree with your opinion that it is deficient
> in the first place.

The fact that it cannot compiler ffmpeg headers is sufficient proof
that is is deficient for the purposes of using ffmpeg headers.

> I don't care about what's broken, as we know that this
> depends on the point of view. Now I'd appreciate if the
> ffmpeg developers acknowledged the existence and the
> interests of developers having to use said platform for
> whatever reason.

OK, here you go:  I, as an ffmpeg developer, acknowledge that there exist
people who wish to use ffmpeg header files with compiler that are not able
to compile them.  Unfortunately, we are unable to accommodate these wishes.

>> > 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.
>
> I hope I could make clear what it is in your stance that
> comes across as provoking.

Yes, I also wish you could do that.

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