For my own education, is there a reason they were passed as void* to
begin with?
On Fri, 2003-03-14 at 23:43, James Devenish wrote:
> In message <[EMAIL PROTECTED]>
> on Fri, Mar 14, 2003 at 05:22:11PM +0000, Wez Furlong wrote:
> > Please coordinate with me on streams issues; if some 64bit oses
> > declare descriptors as longs rather than ints, then we could have a
> > bigger job on our hands (similar to the mess with socket types under
> > win32).
>
> Regardless of any potential disasters with _php_stream_cast, there are
> at least a few unsubtle storage-type conflicts. In my case, fds are
> stored as ints but PHP casts them to pointers.
>
> In message <[EMAIL PROTECTED]>
> on Fri, Mar 14, 2003 at 11:00:50AM -0500, David Hill wrote:
> > Sorry but I don't commit what I don't understand, and the three streams
> > files needed some more understanding on my part. In those areas the php5
> > head differs quite a bit from the 4_3 stream.
>
> Regardless of what you personally understand (and what I personally
> understand), my point would be that the problems are simply unfixed
> by *anyone*.
>
> Even so, I don't know what would be hard for anyone to understand about
> my patches (and no-one has asked me in the past). If you think there
> simply too many of them, most of them are probably whitespace
> disagreements between what you committed and what the PHP style appears
> to be. The basis of all my streams patches is like this (from the old
> streams.c):
>
> Index: main/streams.c
> ===================================================================
> RCS file: /repository/php4/main/Attic/streams.c,v
> retrieving revision 1.125.2.37
> diff -u -u -r1.125.2.37 streams.c
> -- main/streams.c 6 Mar 2003 20:58:19 -0000 1.125.2.37
> +++ main/streams.c 8 Mar 2003 10:48:16 -0000
> @@ -1532,7 +1532,7 @@
> }
> if (ret) {
> fflush(data->file);
> - *ret = (void*)fd;
> + *(int*)ret = fd;
> }
> return SUCCESS;
> default:
>
> What have I done? Well, someone's taking fd (declared as an 'int', which
> may be 32 bits on some systems), casting it a void* (a 64-bit value on
> some systems) and then stuffing that into storage space which, although
> it might not be obvious, happens to be only 32 bits wide. My patch takes
> fd (the 'int') and stuffs it into 'int' storage. Now that's not to say
> that the destination IS actually an 'int' but merely that I am keeping
> the int at its original width rather than casting it up. It's not a
> 'perfect solution', but it's not a 'perfect problem', either.
--
Chris Field <[EMAIL PROTECTED]>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
