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

[Måns Rullgård]

Daniel Verkamp <daniel at drv.nu> writes:

> 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?

Use words like "any" with care.  MIPS64 in the usual configuration has
32-bit userspace pointers.

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

Exactly.

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