[FFmpeg-devel] [PATCH] Use intptr_t

[Michael Niedermayer]

On Mon, Mar 16, 2009 at 03:15:17PM -0300, Ramiro Polla wrote:
> Hi,
> 
> 2009/3/16 M?ns Rullg?rd <mans at mansr.com>:
> > Ramiro Polla <ramiro.polla at gmail.com> writes:
> >> diff --git a/libavformat/file.c b/libavformat/file.c
> >> index bec991a..b11737a 100644
> >> --- a/libavformat/file.c
> >> +++ b/libavformat/file.c
> >> @@ -36,7 +36,7 @@
> >> ?static int file_open(URLContext *h, const char *filename, int flags)
> >> ?{
> >> ? ? ?int access;
> >> - ? ?int fd;
> >> + ? ?intptr_t fd;
> >
> > I wouldn't do that. ?The correct type for a file descriptor is 'int',
> > nothing else.
> 
> Patch updated.
> 
> >> ? ? ?av_strstart(filename, "file:", &filename);
> >>
> >> @@ -59,32 +59,32 @@ static int file_open(URLContext *h, const char *filename, int flags)
> >>
> >> ?static int file_read(URLContext *h, unsigned char *buf, int size)
> >> ?{
> >> - ? ?int fd = (int) h->priv_data;
> >> + ? ?int fd = (intptr_t) h->priv_data;
> >> ? ? ?return read(fd, buf, size);
> >> ?}
> >
> > This should be safe since intptr_t is guaranteed to preserve all bits
> > from the pointer. ?If pointers are smaller than int, the code was
> > already broken.
> 
> Is (intptr_t) or (int) safe?
> 
> Ramiro Polla

> 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)
i mean int and long are guranteed to be safe and correct 
(at least if they are unsiged), its the compiler that is silly

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090316/3479a4b3/attachment.pgp>