[Ffmpeg-devel] [PATCH] Correct inttypes.h emulation for Visual Studio
Mon Dec 4 13:44:22 CET 2006
--- Diego Biurrun <diego at biurrun.de> wrote:
> On Mon, Dec 04, 2006 at 10:52:28AM +0100, Stefan Heinzmann
> > --- M?ns Rullg?rd <mru at inprovide.com> wrote:
> > > In that case, please go away now. We don't want to
> > > with you.
> > Who is 'we'? The list? The orthodox ffmpeg purists as
> > to the M$-heretics? Or pluralis majestatis?
> You did note that it was not the "orthodox ffmpeg purists"
> that started
> flinging around terms like "hate" and similar when they
> were told that a
> patch was rejected, didn't you?
Oh, sure I noted this. I would not have used this term and it
was rightly rebuked. I can understand how it came about,
however, and that has got a lot to do with how people like
Alexander are being treated. If you point a finger at someone
remember that three are pointing back at you.
> How come that you will immediately get written of as
> "orthodox purist"
> when you insist that a workaround has to be made in a
> general way, not
> as a library-specific hack? As a "gcc lover" when the
> problem has
> nothing to do with gcc? As a "Linux-only type" when the
> problem has
> nothing to do with operating systems at all? As "opposing
> when you insist on general (and thus really portable!)
> solutions instead
> of system-specific bandaids?
It comes from a questionable assertion of facts, of which it
is not unreasonable to assume that it tries to hide a deeper
layer of contempt. One is reading between the lines here, and
this is always fraught with the danger of treating someone
unfairly, but I am convinced that there is a grain of truth
in such assumptions, and I would not consider myself a
As I stated in my other post the alledged facts and purely
technical reasons are in reality based on personal opinion,
and merely acknowledging so would already take a lot of bite
out of the debate.
M?ns' opinion: "int64_t etc are not "Unix" types, they're
standard C types. So it's not a difference between Unix and
Windows, but a difference between C and Microsoft's so-called
"C" compilers which do not quite support C." is an example of
his bias. C89 compilers have not suddenly stopped being C
compilers the moment C99 was issued. If anything they have
stopped being *standard* C compilers, and even this is rather
legalistic, relying on the notion that C99 has made C89 null
and void. Giving his point of view do we actually have any C
compiler at all? AFAIK all current C compilers do not quite
support C in *this* sense. Add to this that M$ does not
actually market their compiler as a C compiler at all, but
merely as a C++ compiler with the capability to compile C89
compliant code, you can see that it is being gaged against a
measure it was not made for and not supposed to hold up to.
So what is so surprising about the suspicion that the
criteria for the C compiler used to compile ffmpeg's public
headers are deliberately pitched against MSVC? The suspicion
may well be wrong, but I am not at all surprised that it
> Portable programming is not accumulating special cases for
> imaginable combination of CPU architecture, operating
> system and
> development environment.
Certainly not. Portable programming is about supporting a
relevant subset of all those combinations. In open source
projects, I am used to the idea of having the user base
decide on what is included in this subset, and not a more or
less arbitrary collection of principles deemed beyond
discussion by a particular group of people.
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
More information about the ffmpeg-devel