Re: [PHP-DEV] 64bit PHP on solaris

[Chris Field]

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 +, 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 -   1.125.2.37
> +++ main/streams.c8 Mar 2003 10:48:16 -
> @@ -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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> 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):

James - speaking for myself - I had no problems with your patch, size,
whitespace or otherwise.

As I mentioned before, I like to understand that which I commit before I do
so. Sometimes seeming illogical code can be correct, and so I try to
understand what is proposed - and sometimes I even learn something new :-)
In the case shown below, I had a hard time tracing the call stack back by
code inspection 'cause I did not understand the mechanisms involved (I do
love these indirect methods of calling things, they make debuging so fun :-)
Now that I understand the semi-tortuous means to arrive at the line in
question, I wholeheartedly endore the following change. All 28 calls that
arrive at this line do indeed pass an int - and that was the real reason I
was holding off - I wanted to check that was the case.

Wez, as streams is your baby - can you commit this ? (How is that for
coordination :-)
Jani, as 4.3.2 is your baby - will you approve it ?

Dave

>
> 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 - 1.125.2.37
> +++ main/streams.c 8 Mar 2003 10:48:16 -
> @@ -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.
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

On Sat, 15 Mar 2003, James Devenish wrote:
> Regardless of what you personally understand (and what I personally
> understand), my point would be that the problems are simply unfixed
> by *anyone*.

This is the first time that anyone has brought this issue to my
attention.

> 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.c6 Mar 2003 20:58:19 -   1.125.2.37
> +++ main/streams.c8 Mar 2003 10:48:16 -
> @@ -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
> ...

There is no need for a patronizing tone here; I can read C code.

I will commit this fix shortly.  Are there any other places in the
streams code that are similarly affected?

--Wez.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[James Devenish]

In message <[EMAIL PROTECTED]>
on Fri, Mar 14, 2003 at 05:22:11PM +, 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 -   1.125.2.37
+++ main/streams.c  8 Mar 2003 10:48:16 -
@@ -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.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

>
> Which part of "please coordinate with me on streams issues" didn't you
> get? ;-)
>
> If there are long vs int issues in streams, please let me know where
> they are and I will fix it.
>
> Thanks :)

Forgive me if I am a bit dense tonight :-) My 15 yr old son is having a lan
party in the basement with about 9 friends and I am tech support and the
wine I am drinking to help things is not helping matters :-) Oh to be young
again LOL.

I will send you the proposed diffs when I get a moment to prepare them and
let you submit them as you probably are a better sanity check.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

On Fri, 14 Mar 2003, David Hill 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).
>
> Tru64 & HP-UX (and I would guess Solaris and the rest) - the descriptor is
> an int, which is part of the problem because the streams code in 4.3 casts
> it wrong.
>
> James sent me a patch that included a cast fix, but I have yet to submit it
> (or try too) because I got caught up in trying to follow the code and then
> got diverted. I will endevor to finish my look at the patch  and see if Jani
> will let me commit it.

Which part of "please coordinate with me on streams issues" didn't you
get? ;-)

If there are long vs int issues in streams, please let me know where
they are and I will fix it.

Thanks :)

--Wez.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> 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).

Tru64 & HP-UX (and I would guess Solaris and the rest) - the descriptor is
an int, which is part of the problem because the streams code in 4.3 casts
it wrong.

James sent me a patch that included a cast fix, but I have yet to submit it
(or try too) because I got caught up in trying to follow the code and then
got diverted. I will endevor to finish my look at the patch  and see if Jani
will let me commit it.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> large patch and probably no one got to check it all out). Then, I
> reposted them (and sent then directly to you, Dave!) a few days ago.

And I got all but the three files merged that are probably causing his
problem too - sigh-

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.

And on top of that I got diverted by a bug in the session stuff too.

Well as I always say in my volunteer posts - if you don't like the job I am
doing - cut my pay, if you like what I am doing you can double it - either
way the result is the same :-)

I will try to get the file descriptors stuff in by early next week.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

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).

--Wez.

On Fri, 14 Mar 2003, David Hill wrote:

> > CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> > large patch and probably no one got to check it all out). Then, I
> > reposted them (and sent then directly to you, Dave!) a few days ago.
>
> And I got all but the three files merged that are probably causing his
> problem too - sigh-
>
> 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.
>
> And on top of that I got diverted by a bug in the session stuff too.
>
> Well as I always say in my volunteer posts - if you don't like the job I am
> doing - cut my pay, if you like what I am doing you can double it - either
> way the result is the same :-)
>
> I will try to get the file descriptors stuff in by early next week.
>
> Dave
>
>
>

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> large patch and probably no one got to check it all out). Then, I
> reposted them (and sent then directly to you, Dave!) a few days ago.

And I got all but the three files merged that are probably causing his
problem too - sigh-

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.

And on top of that I got diverted by a bug in the session stuff too.

Well as I always say in my volunteer posts - if you don't like the job I am
doing - cut my pay, if you like what I am doing you can double it - either
way the result is the same :-)

I will try to get the file descriptors stuff in by early next week.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[James Devenish]

In message <[EMAIL PROTECTED]>
on Thu, Mar 13, 2003 at 02:05:45PM -0500, David Hill wrote:
> > > first file_get_contents & readfile both core dump with bus errors
> b/c
> > > the file descriptors are typed as int's when they should be longs
> > > (steams.c lines 1020/1156)
> 
> The lines don't match up to the current code... if you could tell me
> based on the current lines or give me a code snippet

CRIPES, people! I posted patches in November 2002 (admittedly, it was a
large patch and probably no one got to check it all out). Then, I
reposted them (and sent then directly to you, Dave!) a few days ago.




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

Chris,
some of these changes went in a few days ago, so you want to:
cvs co -r PHP_4_3 php4
or grab the release candidate.

> > first file_get_contents & readfile both core dump with bus errors
b/c
> > the file descriptors are typed as int's when they should be longs
> > (steams.c lines 1020/1156)

The lines don't match up to the current code... if you could tell me
based on the current lines or give me a code snippet

> > third, and even stranger, is in php_spn_common_handler it calls:
> > zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|ll", &s11,
> > &len1, &s22, &len2, &start, &len)

Until a few days ago - there was an int/long issue with many calls to
zend_parse_parameter. s need an int, l needs a long. I *think* all of
these are fixed correctly.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

Of the PHP_4_3 branch?

Could you open a bug report for each of these three issues at
bugs.php.net?

--Wez.

On Thu, 13 Mar 2003, Chris Field wrote:

> I am working off a checkout from about three days ago...
>
> On Thu, 2003-03-13 at 11:21, Wez Furlong wrote:
> > Make sure that you are using the latest stable snapshot from
> > http://snaps.php.net; a number of 64bit issues have already been addressed.
> >
> > --Wez.
> >
> > On Thu, 13 Mar 2003, Chris Field wrote:
> >
> > > We have been attempting to run php on a brand new sun v880, and have had
> > > a number of problems.
> > >
> > > first file_get_contents & readfile both core dump with bus errors b/c
> > > the file descriptors are typed as int's when they should be longs
> > > (steams.c lines 1020/1156)
> > >
> > > second, and far stranger is when you open a file with the mode 'a' it
> > > opens it the does a seek using SEEK_CUR which leaves the file pointer at
> > > the beginning of the file, shouldn't that bee a SEEK_END?  Altering that
> > > results in expected functionality, will it break anything else?
> > >
> > > third, and even stranger, is in php_spn_common_handler it calls:
> > > zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|ll", &s11,
> > >   &len1, &s22, &len2, &start, &len)
> > >
> > > the va_list has the correct values for the length of the two strings
> > > passed in, however the lengths are never assigned into len1 and len2, as
> > > it seems they should be.  Any ideas about why this is, I am kind of at a
> > > loss, in the mean time I simply set the lengths of the two strings in
> > > php_spn_common_handler after the parse_parameters function returns which
> > > fixes it.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Chris Field]

I am working off a checkout from about three days ago...



On Thu, 2003-03-13 at 11:21, Wez Furlong wrote:
> Make sure that you are using the latest stable snapshot from
> http://snaps.php.net; a number of 64bit issues have already been addressed.
> 
> --Wez.
> 
> On Thu, 13 Mar 2003, Chris Field wrote:
> 
> > We have been attempting to run php on a brand new sun v880, and have had
> > a number of problems.
> >
> > first file_get_contents & readfile both core dump with bus errors b/c
> > the file descriptors are typed as int's when they should be longs
> > (steams.c lines 1020/1156)
> >
> > second, and far stranger is when you open a file with the mode 'a' it
> > opens it the does a seek using SEEK_CUR which leaves the file pointer at
> > the beginning of the file, shouldn't that bee a SEEK_END?  Altering that
> > results in expected functionality, will it break anything else?
> >
> > third, and even stranger, is in php_spn_common_handler it calls:
> > zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|ll", &s11,
> > &len1, &s22, &len2, &start, &len)
> >
> > the va_list has the correct values for the length of the two strings
> > passed in, however the lengths are never assigned into len1 and len2, as
> > it seems they should be.  Any ideas about why this is, I am kind of at a
> > loss, in the mean time I simply set the lengths of the two strings in
> > php_spn_common_handler after the parse_parameters function returns which
> > fixes it.
> >
> >
> > --
> > Chris Field
> > [EMAIL PROTECTED]
> > Affinity Solutions Inc.
> > 386 Park Avenue South
> > Suite 1209
> > New York, NY 10016
> > (212) 685-8748 ext. 32
> >
-- 
Chris Field
[EMAIL PROTECTED]
Affinity Solutions Inc.
386 Park Avenue South
Suite 1209
New York, NY 10016
(212) 685-8748 ext. 32


signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

Make sure that you are using the latest stable snapshot from
http://snaps.php.net; a number of 64bit issues have already been addressed.

--Wez.

On Thu, 13 Mar 2003, Chris Field wrote:

> We have been attempting to run php on a brand new sun v880, and have had
> a number of problems.
>
> first file_get_contents & readfile both core dump with bus errors b/c
> the file descriptors are typed as int's when they should be longs
> (steams.c lines 1020/1156)
>
> second, and far stranger is when you open a file with the mode 'a' it
> opens it the does a seek using SEEK_CUR which leaves the file pointer at
> the beginning of the file, shouldn't that bee a SEEK_END?  Altering that
> results in expected functionality, will it break anything else?
>
> third, and even stranger, is in php_spn_common_handler it calls:
> zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|ll", &s11,
>   &len1, &s22, &len2, &start, &len)
>
> the va_list has the correct values for the length of the two strings
> passed in, however the lengths are never assigned into len1 and len2, as
> it seems they should be.  Any ideas about why this is, I am kind of at a
> loss, in the mean time I simply set the lengths of the two strings in
> php_spn_common_handler after the parse_parameters function returns which
> fixes it.
>
>
> --
> Chris Field
> [EMAIL PROTECTED]
> Affinity Solutions Inc.
> 386 Park Avenue South
> Suite 1209
> New York, NY 10016
> (212) 685-8748 ext. 32
>

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php