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

[Stefan Heinzmann]

--- Diego Biurrun <diego at biurrun.de> wrote:

> On Mon, Dec 04, 2006 at 10:52:28AM +0100, Stefan Heinzmann
> wrote:
> > --- M?ns Rullg?rd <mru at inprovide.com> wrote:
...
> > > 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?
> 
> 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
> portability"
> 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
M$-lover.

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

> Portable programming is not accumulating special cases for
> every
> 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.

Cheers
Stefan



	

	
		
___________________________________________________________ 
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de