[Ffmpeg-devel] PATCH Blackfin UNALIGNED_STORES_ARE_BAD in bitstream.h

Rich Felker dalias
Wed Apr 18 15:57:08 CEST 2007


On Wed, Apr 18, 2007 at 11:23:34AM +0200, Fran?ois Revol wrote:
> > It can be documented in a porting file or something. But I strongly
> > object to having blatently nonportable code in the default build. If
> > I
> > were trying to compile ffmpeg on a strange system and not a competent
> > coder/debugger, I would have no idea why it crashed and probably just
> > assume it was nonportable crapware rather than learning how to
> > investigate and "fix" the problem.
> 
> Indeed, but ppl on BeOS will currently assume nonportable crapware
> because it will fail to build on PRI* macros... just because someone
> assumes "portable" to mean porting the OS to ffmpeg instead of the
> other way around. but that's another story.

No, the difference is that these are part of the standard C language,
and BeOS does not conform to the standard.

> > 1. Enable the nonportable code by default but have a
> > --disable-nonportable-assumptions option to configure, or an
> > ARCH_GENERIC define included in the above list that configure would
> > define when the arch is unknown to inhibit all such optimizations.
> 
> Why an option a newbie wouldn't know about ?
> You're just shuffling the problem around.

OK fair enough.

> > 2. Just have configure print a message directing users to a porting
> > document with references to this line and other similar lines when an
> > unknown arch is detected.
> 
> #if !defined(..)
> ....
> #endif
> #ifdef ARCH_GENERIC
> #warning "FIXME: Unknown arch, assuming strict alignment. This could be
> subobtimal!!!"
> #endif

Looks good to me.

> > > if it crashes and the person sends a bugrport its trivial to add
> > > the arch
> > > if its just slower than what it could be nothing will happen it
> > > will always
> > > stay slow
> >
> > This assumes the code is maintained and the user is using the latest
> > version. The problem is what happens 10 years from now if ffmpeg is
> 
> That's assuming gcc will be around in 10 years ;)

:) :) :) :) :)

Rich




More information about the ffmpeg-devel mailing list