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

[Stefan Heinzmann]

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

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.

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.

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

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

> > 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 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 ;-)

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

> > 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. They may instead hold the opinion that
ffmpeg itself is deficient. That probably won't make any
particular difference to you, but it shows again that we're
in the realms of personal opinions, and not the realms of
undisputable facts.

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

I don't think that anyone would demand that you or any of the
other "core" developers add another platform to the ones you
check on a regular basis. I am confident that the developers
using MSVC would do that themselves, and howl here when
something has stopped working, if only they had the feeling
that they are being accepted as part of the community here.
Facing the same old battle each time a patch is proposed does
not create this feeling however. Your being so dismissive
contributes in creating the problem you moan about.

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

Given what I wrote above, I hope you can appreciate that this
sounds quite patronizing to those who happen to differ from
your point of view. Let me paraphrase this to get my point
across:

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.

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

Cheers
Stefan


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