[FFmpeg-devel] [PATCH] Make HAVE_FAST_UNALIGNED allow unaligned memory accesses

Reimar Döffinger Reimar.Doeffinger
Tue Jul 15 21:30:45 CEST 2008


On Tue, Jul 15, 2008 at 08:23:12PM +0100, M?ns Rullg?rd wrote:
> > diff --git a/libavutil/intreadwrite.h b/libavutil/intreadwrite.h
> > index cbf5163..12dec54 100644
> > --- a/libavutil/intreadwrite.h
> > +++ b/libavutil/intreadwrite.h
> > @@ -23,6 +23,8 @@
> >  #include "config.h"
> >  #include "bswap.h"
> >
> > +#if !defined(HAVE_FAST_UNALIGNED)
> > +
> >  #ifdef __GNUC__
> >
> >  struct unaligned_64 { uint64_t l; } __attribute__((packed));
> > @@ -37,7 +39,19 @@ struct unaligned_16 { uint16_t l; } __attribute__((packed));
> >  #define AV_WN32(a, b) (((struct unaligned_32 *) (a))->l) = (b)
> >  #define AV_WN64(a, b) (((struct unaligned_64 *) (a))->l) = (b)
> >
> > -#else /* __GNUC__ */
> > +#elif defined(__DECC)
> > +
> > +#define AV_RN16(a) (*((const __unaligned uint16_t*)(a)))
> 
> Yes, these ifdefs should be replaced with checks for the required
> compiler features in configure.  If we agree to this change, I'll
> add such checks, and update the patch.

can the current __GNUC__ be checked reliably? That
__attribute__((packed)) acts as "unaligned marker" for structs with only
one element is something that on first sight I would consider a compiler
bug, in which case it would be really hard to check for...




More information about the ffmpeg-devel mailing list