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
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 *
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
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
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
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:
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
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:
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
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
# 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
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
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:
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
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
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 -
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 -
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 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
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
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
21 matches
Mail list logo
