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

[Daniel Verkamp]

On Sun, Mar 1, 2009 at 1:57 AM, Dominik 'Rathann' Mierzejewski
<dominik at rangers.eu.org> wrote:
> 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?

Converting 32 -> 64 -> 32 bits is fine; nothing is lost.

>
> Regards,
> R.
>

Thanks,
-- Daniel Verkamp