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

[Måns Rullgård]

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

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