[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