[FFmpeg-devel] [RFC] rtsp.c EOF support

[Dominik 'Rathann' Mierzejewski]

On Saturday, 28 February 2009 at 19:51, M?ns Rullg?rd wrote:
> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
> 
> > Hi,
> >
> > On Sat, Feb 28, 2009 at 12:32 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> On Sat, Feb 28, 2009 at 08:28:28AM -0500, Ronald S. Bultje wrote:
> >>> On Sat, Feb 28, 2009 at 8:19 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >>> > On Sat, Feb 28, 2009 at 12:56:29AM -0500, Ronald S. Bultje wrote:
> >>> >> Index: ffmpeg-svn/libavformat/file.c
> >>> >> ===================================================================
> >>> >> --- ffmpeg-svn.orig/libavformat/file.c ? ? ? ?2009-01-23 20:03:59.000000000 -0500
> >>> >> +++ ffmpeg-svn/libavformat/file.c ? ? 2009-02-28 00:12:52.000000000 -0500
> >>> >> @@ -82,6 +82,11 @@
> >>> >> ? ? ?return close(fd);
> >>> >> ?}
> >>> >>
> >>> >> +static int file_get_handle(URLContext *h)
> >>> >> +{
> >>> >> + ? ?return (size_t)h->priv_data;
> >>> >> +}
> >>> >
> >>> > why size_t -> int ?
> >>> > these types arent the same, which is wrong for the handle?
> >>>
> >>> file.c uses size_t, but all other protocols use int. Which do you
> >>> prefer? I'll just change either one.
> >>
> >> the correct one
> >> open() in POSIX/ISO C has a type and only that is correct
> >> i think its int but didnt check, i rathet try to review a few more
> >> patches or fix a few more serious bugs than check POSIX now.
> >
> > POSIX says int. I think file.c uses size_t since it's long (is it?)
> 
> size_t is some unspecified, unsigned type.
> 
> > and that always fits a pointer.
> 
> Neither long nor size_t are guaranteed to hold a pointer.  intptr_t is
> an integer type at least as wide as a pointer.  There is no integer
> type guaranteed to be smaller or equal to a pointer.
> 
> > Basically the thing is saved directly
> > (literally: int fd = open(..); h->priv_data = (void *) (size_t) fd;).
> > I don't quite know if it would upset 64bit computers (or compilers) if
> > I just changed it to int, but basically the whole thing is assured to
> > be 32bits, it's just stored in a long-value in case the pointer is
> > 64bit...
> 
> Converting from int to pointer and back should be safe on all systems
> we care about.

I'm probably missing something here, but pointers on x86_64 (and any 64bit
arch) are 64bit, while int isn't, so why are you saying it's safe?

Regards,
R.

-- 
MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan