[FFmpeg-devel] [PATCH] remove MSVC cruft

Rich Felker dalias
Wed Feb 13 19:43:27 CET 2008


On Wed, Feb 13, 2008 at 06:32:25PM +0800, mvplayer wrote:
> +1
> 
> FFmpeg heavily depends on gcc inline asm which is gcc specific extensions
> and is not portable

No it does not. It works perfectly well on any remotely-POSIXish C
environment as long as uname does not report something that looks like
an i386 or other known cpu arch. In this latter case, GNU-specific asm
constructs are enabled without testing if they work and they replace
the corresponding C code. This is what needs to be fixed.

> I do not think it is a clever solution

Top-posting is not clever either...

Rich

> On Feb 13, 2008 5:02 PM, Diego Biurrun <diego at biurrun.de> wrote:
> 
> > On Wed, Feb 13, 2008 at 09:56:46AM +0100, Reimar D?ffinger wrote:
> > > On Tue, Feb 12, 2008 at 08:50:01PM -0500, Rich Felker wrote:
> > > > On Tue, Feb 12, 2008 at 07:15:22PM +0100, Michael Niedermayer wrote:
> > > > > > It's two seconds for anyone to fix who knows what they are doing.
> > > > >
> > > > > Why should a user of a plain ISO C (no asm) compiler have to fix
> > anything
> > > > > when compiling a program which is supposedly ISO C compared to GNU
> > C?
> > > >
> > > > Indeed, this sort of attitude makes me so mad. I spent many hours on
> > > > such "two second fixes" for countless programs when building them on
> > > > my system, all due to idiotic GNU assumptions.
> > >
> > > I do not see how assuming that GNU is the only compiler implementing
> > > asm() is much better, even TurboPascal had an asm thing.
> > > And for those people it will be more like a two-hour fix to even find
> > > out what is going wrong...
> > > In addition there seem to be some asms that are not conditional at all.
> > > The suggestions here IMO have _not at all_ been about fixing compilation
> > > with a plain C compiler, but instead about hacking around and pretending
> > > to do this without considerations to the problems it might cause.
> >
> > I second that thought.  Lots of flames, very little consideration of the
> > code we are actually talking about.
> >
> > Diego
> >  _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at mplayerhq.hu
> > https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> >
> 
> 
> 
> -- 
> ----------------------------------------
> Inspired by http://www.mvplayer.net
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel




More information about the ffmpeg-devel mailing list