[FFmpeg-cvslog] r11679 - trunk/libavcodec/apedec.c

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Thu, Jan 31, 2008 at 01:59:35AM +0000, M?ns Rullg?rd wrote:
>> bcoudurier <subversion at mplayerhq.hu> writes:
>> 
>> > Author: bcoudurier
>> > Date: Thu Jan 31 01:10:56 2008
>> > New Revision: 11679
>> >
>> > Log:
>> > cast to correct type, fix warning: apedec.c:859: warning: passing argument 1 of 's->dsp.bswap_buf' from incompatible pointer type
>> >
>> > Modified:
>> >    trunk/libavcodec/apedec.c
>> >
>> > Modified: trunk/libavcodec/apedec.c
>> > ==============================================================================
>> > --- trunk/libavcodec/apedec.c	(original)
>> > +++ trunk/libavcodec/apedec.c	Thu Jan 31 01:10:56 2008
>> > @@ -856,7 +856,7 @@ static int ape_decode_frame(AVCodecConte
>> >
>> >      if(!s->samples){
>> >          s->data = av_realloc(s->data, (buf_size + 3) & ~3);
>> > -        s->dsp.bswap_buf(s->data, buf, buf_size >> 2);
>> > +        s->dsp.bswap_buf((uint32_t*)s->data, (uint32_t*)buf, buf_size >> 2);
>> 
>> Is proper alignment guaranteed here?
>
> No, the return of av_realloc() has no guranteed alignment beyond what is
> needed by C code on the architecture. Though i have some doubt that theres
> a platform out there having less than aligned by 4 values comming out of
> realloc() ...

Memory from malloc() and friends is guaranteed to be suitable for any
standard C type on the machine.  I just wasn't sure where the pointer
came from in the first place (yeah, I could have checked).

-- 
M?ns Rullg?rd
mans at mansr.com