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

[Stefan Heinzmann]

--- M?ns Rullg?rd <mru at inprovide.com> wrote:

> "Alexander Chemeris" <ipse.ffmpeg at gmail.com> writes:
> 
> > On 12/4/06, Mike Melanson <mike at multimedia.cx> wrote:
> >> Alexander Chemeris wrote:
> >> >> It's very sad that you think we 'hate' a compiler
> just because we choose
> >> >> not to proactively support it.
> >> > Applying this patch will take less time for you then
> writing all this
> >> > flame mails.
> >> Sending a patch to the list in no way guarantees that it
> will or even
> >> should be applied.
> > I understand this clearly. I've just surprised of some
> people flame reaction
> > on my request.
> 
> 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.

> >> > 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?

> > 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$.

Tools and environments deficiencies are a sad fact of life
which can not always be dealt with in 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.

MSVC and Windows will not go away anytime soon and no amount
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.

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. In my opinion it is merely
acknowledging that a workaround is needed for a popular
platform.

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.

Sorry for the rant, but it's sometimes unavoidable.

Cheers
Stefan



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de