Re: [PHP-DEV] 64bit PHP on solaris
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit PHP on solaris
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit PHP on solaris
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit PHP on solaris
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit PHP on solaris
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit PHP on solaris
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
Aside from renaming the php-dev list, we should remove the 'PHP and Zend Engine internals lists' from the regular mailing list page, put them in a 'developers' section (name isn't important) that describes cvs access, dev email lists, how to build (ie. win32 libraries), etc. As a newbie commiter, still wet behind the ears, I would have *really* appreciated a page that was a little clearer and a bit more up to date than what I started with. My sources of information README.CVS-RULES, the building from cvs web page) were very good, but missed some vital clues. While many have been very patient with me (thanks), I found it frustrating to ask questions that seem to be obvious to others like: * trying to build php4 head for two days, only to be told that I should be building PHP_4_3 or php5 head. * forgetting about re2c, which is not mentioned anywhere that I could find, but I found through freshmeat and had a lovely time trying to build :-) I am taking note of the problems I encountered and was planning on updating something (README.CVS-RULES ?) after another week or so. Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Further outstanding 64-bit issues with PHP_4_3
Thanks, will look at these and see if I can't get them in with Jani's permission. The OnUpdateLong is in my cvs queue, but I was getting a karma issue on Friday. Out of curiosity - which platform do you use ? I am on Tru64 and am working with the HP-UX folks. It would be interesting to know what other 64bit platforms are being covered/used. Once I went to the PHP_4_3 tree I did not encounter any configuration issues, other than the flex check, and as I had backed off to an older version, that was not a problem either for me anymore. Dave Just looking at CVS diffs (can't compile at the moment due to ./configure breakage), I can see... Remaining zend_parse_parameters problems: php4/ext/ftp/php_ftp.c php4/ext/sockets/sockets.c General LP64 incompatabilities left over from my November patches: php4/ext/pgsql/pgsql.c php4/ext/standard/url_scanner.c php4/ext/standard/url_scanner_ex.c php4/main/network.c php4/main/streams.c (Need to check: is _php_stream_cast safe? If not, then main/streams/cast.c in HEAD is probably not) php4/main/streams/plain_wrapper.c php4/main/streams/xp_socket.c And of course the OnUpdateLong stuff, but I guess that's in process. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
What does this output? flex -V -v --version 2/dev/null - Sascha # flex-2.5.27/flex -V -v --version 2/dev/null flex 2.5.27 # flex-2.5.4/flex -V -v --version 2/dev/null flex-2.5.4/flex version 2.5.4 Nice consistancy eh ? Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
# flex-2.5.27/flex -V -v --version 2/dev/null
flex 2.5.27
This should be parsed correctly. What kind of OS and /bin/sh
OS == Tru65, shell is /bin/sh
do you have?
What does
ver1=2.5.27
ver2=2 5 27
set $ver2; echo $3
27
IFS=.; set $ver1; echo $3
27
The test in php4/configure.in (and php5/configure.in) is
set `echo | $LEX -V -v --version 2/dev/null | grep 'version' |
cut -d ' ' -f
3 | sed -e 's/\./ /g' | sed -e 's/[^0-9 ]//g'`
if test ${1} != 2 -o ${2} != 5 -o ${3} -lt 4; then
In the newer flex output it does not have the work 'version' in it,
and the version is the second not the third arg which is why this test
fails.
changing that to
set `echo | $LEX -V -v --version 2/dev/null | sed -e 's/^.*
//' -e 's/\./ /g'
works for me in both cases. It also handles this case:
# flex-2.5.4/flex -v -V --version 21
flex-2.5.4/flex version 2.5.4
which has a double version number.
Dave
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
I set up a debian linux box and after getting the right versions of
things I am still getting the same results from configure. I am
getting a syntax error saying else unexpected.
With php5 module HEAD?
No - php4 HEAD, should I be doing this with php5 instead ?
What line is the error at?
What does running the build/buildcheck.sh script output
for the tool versions?
# ./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.5 (ok)
buildconf: libtool version 1.4.3 (ok)
rebuilding configure
rebuilding acconfig.h
rebuilding main/php_config.h.in
# CC='cc -std1' ./configure (I normally add more options - but I am
trying to get the simple case to work)
...
checking style of sigwait... other
checking style of sigwait... other
checking for mysqli support... no
-l
./configure[53629]: syntax error at line 53630 : `else' unexpected
$ODBC_LIBDIR/lib${ac_solid_prefix}${ac_solid_os}${ac_solid_version}.so
echo
*
else
ODBC_LFLAGS=-L$ODBC_LIBDIR
ODBC_LIBS=-l${ac_solid_prefix}${ac_solid_os}${ac_solid_version}
fi
echo $ac_t`echo $ODBC_LIBS | sed -e 's!.*/!!'` 16
else 53629
echo $ac_tno 16
fi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
Thank you all for you tips and pointers on this build issue. Once I switched to the PHP_4_3 tree I things got much better :-) I built it and hand installed the .so and am seeing a phpinfo() page in my browser. Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
You shouldn't :) m4-1.4 without the 'o'. Thanks ! That does help some. I don't get the buildconf warnings now, but I am still getting shell syntax errors in the resulting configure script. arrrgh :-p Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fun with autoconf on Tru64
Thanks ! That does help some. I don't get the buildconf warnings now, but I am still getting shell syntax errors in the resulting configure script. arrrgh :-p Make sure that autoconf-2.13 is completely reinstalled (including rm -rf autoconf-2.13). Otherwise, the frozen files which were generated using m4-1.4o cause problems. Thanks, I did purge my tools tree and rebuilt all of them. Moving on to the next bug, it would seem that flex changed how it reports versions differently # ./flex --version ./flex version 2.5.4 # ./flex --version flex 2.5.27 and the code that checks for the right flex will work right with 2.5.4 but not with 2.5.27, the result is a set command with no args which causes my env to be burped out. The change is needed in configure.in (I think). So I backed up to flex 2.5.4 :-p After that, I get a syntax error related to ext/odbc/config.m4. Don't understand why, but I get a script block that is missing the first half of an if then else fi construct. I tried working around this by zeroing the config.m4 file, as I am not using odbc anyway, but that only moved the problem down a module or two. I set up a debian linux box and after getting the right versions of things I am still getting the same results from configure. I am getting a syntax error saying else unexpected. I encountered what appears to be a typo in odbc/config.m4: + PHP_EVAL_LIBLINE([$ODBC_LFLAGS $ODBC_LIBS], OBDC_SHARED_LIBADD) that should probably be ODBC, but it had nothing to do with my build problem. At this point I have spent about 10 hours on this and am no closer to being able to build test my changes. Anyone have any ideas ? Anyone want to send me a ./configure that works with HEAD ? As I can only compile a part of the zend_parse_parameter changes I have proposed, I will becommiting them anyway in a moment. I will also need to commit the OnUpdateInt/Long changes tommorow (friday) so Jani can do the 4.3.2 kit. Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - 64 bit issue with zend_parse_parameters calls
Just commit these.. I will - give me a couple of days though - given that it is my first commit with php I want to triple check that I have got the process correct before I push the button :-) Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
A single API is probably sufficient but I can understand that extension writers might want to use ints. The INI flag might have nothing to do with an internal zval and an int might be more than enough. I don't really mind but I wouldn't introduce OnUpdateInteger. I guess we should either move everything to OnUpdateLong() and nuke OnUpdateInt() in ZE2 or we change OnUpdateInt to work with ints and fix the whole code. It might be less confusing to just have one. I agree about the confusing part. My suggestion is: * we leave OnUpdateInt as is currently for BC, deprecating it now, removing it in (? php 5.x == ZE2 ?) * convert everything in the code base to OnUpdateLong, which means I change the arguments passed into the call where needed (yipee I get to do another code sweep :-) This fixes the symantic problem and sets the stage for how to proceed in the future. * update the documentation with a note reminding people that int and long are not the same thing, both for OnUpdateInt and for zend_parse_parameters (I found zend_parse_parameters in the docs but not OnUpdateInt, any hints ?) I *think* this would work with all of the comments I have seen on this issue. I will start coding today, and if people are ok with it I will commit on Friday (to allow time for comment) so that Jani can move on 4.3.2. dave
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
So for 4.3.2, we add the OnUpdateLong() and replace all the calls to OnUpdateInt() to use that instead and we leave the OnUpdateInt() behaviour same as it was. This shouldn't cause BC problems then..? If you want to leave the current OnUpdateInt behavior (uses long * internally) ... then that will require some additional changes, as there are a dozen or so places where an int is currently passed to OnUpdateInt, which I left as is because I changed to using OnUpdateLong where a long was used. Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ddhill
Would like to contribute 64 bit related corrections to PHP core and extensions. Will be feeding changes found by the HP Tru64 and UX teams back. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
The patch I sent in should have all of the OnUpdateLong changes in them, and the remaining OnUpdateInt should probably be OnUpDateInteger. The painful part was actually looking at what was passed to match up the calls. That might save you some time. dave hill Yes, I know, but we need to remain backwards compatible so I'm adding OnUpdateInteger() and OnUpdateLong(). This leaves OnUpdateInt() as it is now. Just need to go through the extensions and change the necessary OnUpdateInt()'s to OnUpdateLong(). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
Is there any specific reason why a single API (OnUpdateLong) is not sufficient? Is not it a safe assumption that those modules which still use 'int's are simply the result of a mistake on the developer's side? This is a reasonable assumption actually I can't think of a case where a long would not work in place of an int. And given that you are talking of only a handfull that would be changed, size would not be an issue. Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt
So I think the fix of adding OnUpdateLong() is the correct fix. I was under the impression that OnUpdateInt was actually expecting a long. I remember changing some int's to long's to address 64 bit issues. Do I remember this incorrectly? - Sascha Most, but not all of the calls to OnUpdateInt were long, and at least one of the mismatches was in main (three longs in a row followed by an int look at output_buffering in main.c). I personally don't care which way the team wants to fix this. My thought was the making the name say long was the best way to avoid silly errors in the future. If you want some consistency, then you could always retire OnUpdateInt and force them all to be long :-) It is not as if an extra few bytes would be noticed. Part of the problem is that many people still think an int and a long are interchangeable - and they actually are when the compiler knows what it is dealing with. The problem is when you start passing pointers around and casting things, and the compiler can't fix things up for you. This is of course compounded by the fact that on quite a few platforms they are the same size Dave Hill -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
