[FFmpeg-devel] [PATCH] remove MSVC-specific

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Sat, Mar 08, 2008 at 09:09:11PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Sat, Mar 08, 2008 at 09:31:03PM +0100, Diego Biurrun wrote:
>> >> On Sat, Mar 08, 2008 at 09:09:47PM +0100, Michael Niedermayer wrote:
>> >> > On Sat, Mar 08, 2008 at 09:03:00PM +0100, Diego Biurrun wrote:
>> >> > > On Mon, Feb 25, 2008 at 03:57:03PM +0100, Diego Biurrun wrote:
>> >> > > > Here is a patch to remove an MSVC-specific definition from
>> >> > > > libavutil/mem.h.  MSVC is not supported and now we have a
>> >> > > > proper fallback.  Besides, it seems that the identifier is
>> >> > > > wrong anyway and the condition is never true.  This proves
>> >> > > > that if there should be any sort of MSVC support, it
>> >> > > > should be maintained outside of FFmpeg where it might
>> >> > > > actually get some testing.
>> >> > > 
>> >> > > No one seemed to be against this patch, so here is an
>> >> > > updated version.
>> >> > 
>> >> > patch rejected :)
>> >> 
>> >> :)
>> >> 
>> >> Seriously, we do not provide MSVC infrastructure in other places, why in
>> >> this one?
>> >
>> > Why not? :))
>> >
>> > Seriously, its one hunk less to maintain for people who have hacked their
>> > ffmpeg to be msvc compileable. And it does no harm to us.
>> 
>> It adds to the maintenance burden for everybody, and it is a piece of
>
> What kind of maintaince can these 2 lines need?

What good do those lines do to the rest of FFmpeg as present in svn?
If the answer is "nothing", they should go.

Two lines never seems like much, but two lines here and two lines
there soon add up to a lot.

> Its like saying the a fourcc in the table of fourccs for a codec we dont
> support adds a maintenance burden for everybody ...

No, it's not.  A table entry will never be rendered incorrect by
code changes.

>> code that will never receive any testing whatsoever.  Both of these
>> are bad.
>> 
>> > Maybe we can one day even support MSVC fully, it just needs MSVC to
>> > support standard C or someone to come up with a clean workaround. Like
>> > a little perl script to convert the problematic syntax before feeding it
>> > to the compiler.
>> 
>> You've obviously never had the misfortune of being required to use
>> msvc for anything.  Or my sarcasm detector is in dire need of
>> maintenance.
>
> No, i was lucky and just had some volunteerly contact with MSVC
> which ended after a week or 2 of twice daily hard resets. That was
> maybe 10 years or so ago IIRC

The situation hasn't improved.

-- 
M?ns Rullg?rd
mans at mansr.com