[FFmpeg-devel] [PATCH] Use intptr_t

[Ramiro Polla]

On Wed, Mar 18, 2009 at 1:59 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Mar 17, 2009 at 05:56:00PM -0300, Ramiro Polla wrote:
>> Hi,
>>
>> On Mon, Mar 16, 2009 at 3:33 PM, Ramiro Polla <ramiro.polla at gmail.com> wrote:
>> >>> diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
>> >>> index 81d25ec..bdb8a8a 100644
>> >>> --- a/libavcodec/atrac3.c
>> >>> +++ b/libavcodec/atrac3.c
>> >>> @@ -230,7 +230,7 @@ static int decode_bytes(const uint8_t* inbuffer, uint8_t* out, int bytes){
>> >>> ? ? ?const uint32_t* buf;
>> >>> ? ? ?uint32_t* obuf = (uint32_t*) out;
>> >>>
>> >>> - ? ?off = (int)((long)inbuffer & 3);
>> >>> + ? ?off = (intptr_t)inbuffer & 3;
>> >>> ? ? ?buf = (const uint32_t*) (inbuffer - off);
>> >>> ? ? ?c = be2me_32((0x537F6103 >> (off*8)) | (0x537F6103 << (32-(off*8))));
>> >>> ? ? ?bytes += 3 + off;
>> >>
>> >> is intptr_t available on all platforms we care about? (its optional per spec
>> >> IIRC)
>> >
>> > It's already being used in a few places in FFmpeg, and nobody complained yet.
>> >
>> >> i mean int and long are guranteed to be safe and correct
>> >> (at least if they are unsiged), its the compiler that is silly
>> >
>> > hmm, the compiler should be able to see that &3 will fit in whatever
>> > int you want, but it doesn't...
>>
>> Updated patches attached.
>> intptr_t_1.diff should be rather harmless.
>> intptr_t_2.diff some people might want to comment some more (I
>> personally don't like the double casting).
>
> which -Wno-blah do we need to add to silence these warnings?

That would be -Wno-pointer-to-int-cast , but IMHO it's not the best way to go.
It did warn about a valid bug on dynarrays (r16986).

Ramiro Polla