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

[Ronald S. Bultje]

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?)
and that always fits 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...

Messy. I guess a cleaner solution would be to have file.c actually
allocate a priv_data structure containing an actual int (similar to
TCPContext), but that would cost one extra av_malloc(). OK if I do
this?

Ronald