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 bas

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 baseme

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 in

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 -

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 -

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 line

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 c

[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

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 To unsubscribe, visit: h

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

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

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

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 >

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 To unsubscribe, visit: http://

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 eith

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 To unsubscribe, visit: http://www.p

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

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 t

[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 To unsubscribe, visit: http://www.php.net/unsub.php

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 * inte

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 al