From:	Chris Field	Date:	Sat Mar 15 09:49:42 2003
Subject:	Re: 64bit PHP on solaris

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 <Pine.LNX.4.53.0303141720530.27207@zaneeb.brainnet.i>
> 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 <003201c2ea42$e3224410$6400a8c0@TheDuck>
> 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 <cfield@affinitysolutions.com>