[FFmpeg-devel] [PATCH] Use intptr_t

[Ramiro Polla]

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).

Ramiro Polla
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intptr_t_1.diff
Type: text/x-patch
Size: 1413 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090317/76424289/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intptr_t_2.diff
Type: text/x-patch
Size: 1435 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090317/76424289/attachment-0001.bin>