[FFmpeg-devel] Patch for folding unaligned access routines into one file

Roman Shaposhnik rvs
Sat Jul 28 06:18:08 CEST 2007


On Fri, 2007-07-27 at 23:30 +0100, M?ns Rullg?rd wrote:
> >   There's even a bigger question at stake here: under what conditions
> > would CONFIG_ALIGN be defined? Why do we have this #ifdef to begin
> > with?
> 
> CONFIG_ALIGN is never set.  Those unaligned32_be/le functions should
> be replaced with AV_R[LB]32.

  Well if nobody chimes in -- that's exactly what I'm going to do in
one of the subsequent patches.

> >   Suggestions? (but then again, it gets undefined right after this block
> > so we shouldn't be spending too many brain cycles inventing a name for
> > it ;-)).
> 
> The problem is if some header included prior to intreadwrite.h
> #defines a macro of the same name.  We have no business defining or
> undefining anything in the common namespace.

  AV_INTERNAL_MISALIGNED_ACCESS ? 

> >> >  #else /* __GNUC__ */
> >> >  
> >> > -#define LD16(a) (*((uint16_t*)(a)))
> >> > -#define LD32(a) (*((uint32_t*)(a)))
> >> > -#define LD64(a) (*((uint64_t*)(a)))
> >> > +#ifdef __DECC
> >> > +#define av_unaligned_type_specifier __unaligned
> >> > +#else
> >> > +#define av_unaligned_type_specifier
> >> > +#endif
> >> 
> >> What happens if !__GNUC__ && !__DECC?  You of all should know...
> >
> >   I do ;-) Unless I goofed up the result should be exactly the same
> > as the original one:
> >
> >    ................................
> >    return *(const uint##x##_t *) v;
> >    ................................
> >
> >   Which, of course, might cause SIGBUS, but that's a separate problem.
> >
> >   Or do you have something else in mind?
> 
> No, SIGBUS is exactly what I had in mind.

  Right. But that's no worse than the originals (both of them). And I 
really don't know what to do if architecture happens to SIGBUS on
misaligned access, yet the compiler doesn't support neither of 
extensions. Ideas?

Thanks,
Roman.





More information about the ffmpeg-devel mailing list