[PHP-DEV] Bug #12585: W3C service stops

[reinhard . faber]

From: [EMAIL PROTECTED]
Operating system: NT 4.0 SP6a
PHP version:  4.0.4pl1
PHP Bug Type: IIS related
Bug description:  W3C service stops

I have a Webserver serving several sites. everything works fine for some
time, but the the w3c service (WWW and FTP) stop working. there are no
entries in the event log or elsewhere (at least I haven't found some)
I can simply startup the www and ftp services again, everything is
fine...

I am using IIS 4 on NT 4.0 with SP6a and ODBC. This happens by using both,
the *.dll and the *.exe version of php

My workaround by now is restarting the webserver every 5 minutes
-- 
Edit bug report at: http://bugs.php.net/?id=12585&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12563 Updated: Imlib2 Issue

[wez]

ID: 12563
Updated by: wez
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Compile Failure
Operating System: RedHat 7.1 / 2.4.7 Kernel
PHP Version: 4.0.6
New Comment:

imlib2 uses AC_ADD_LIBRARY and friends instead of PHP_ADD_LIBRARY and friends in it's 
config.m4; it is broken
against CVS, but can be fixed easily.

--Wez.

Previous Comments:


[2001-08-05 20:20:09] [EMAIL PROTECTED]

The Imlib2 guys say it's a PHP bug:

> I reported what I thought to be a PHP bug, they say it's a bug in Imlib2.
> Please have a look.

I don't see how this can be an imlib2 bug. it's a bug in php's autoconf/make
etc. setup - probably related to how they do imlib2 detection and li checking.

they should use imlib2-config

[- 10:07AM ~ -]imlib2-config --version
1.0.4
[- 10:07AM ~ -]imlib2-config --cflags 
-I/usr/local/include -I/usr/X11R6/include
[- 10:07AM ~ -]imlib2-config --libs  
-L/usr/local/lib -lImlib2 -lttf -lm -ldl -lXext -lXext -lX11 -L/usr/X11R6/lib
[- 10:07AM ~ -]imlib2-config --prefix
/usr/local
[- 10:07AM ~ -]imlib2-config --help
Usage: imlib2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--libs]
[--cflags]

to figure out cflags and link flags.

this is likely a type.missing character or missing logic statement in their
build procedure. it's not an imlib2 bug - unless your imlib2-config is spewing
out empty results for --libs or --cflags... which it shoudln't.




[2001-08-04 00:19:43] [EMAIL PROTECTED]

Not a PHP bug. Report this to the imlib author instead.




[2001-08-04 00:17:05] [EMAIL PROTECTED]

make fails while trying to add Imlib2 support.

./configure --with-xml --with-apxs=/usr/sbin/apxs --with-mysql=/usr --with-pgsql 
--with-imlib

I can see the configure script finds my new Imlib2 install:


checking for imlib2 support... yes
checking for imlib_load_image in -lImlib2... yes


anyway, here's the error:

Making all in .
make[1]: Entering directory `/usr/src/php-4.0.6'
/bin/sh /usr/src/php-4.0.6/libtool --silent --mode=link gcc  -I.
-I/usr/src/php-4.0.6/ -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6
-I/usr/include/apache -I/usr/src/php-4.0.6/Zend -I/usr/include/mysql
-I/usr/src/php-4.0.6/ext/xml/expat/xmltok
-I/usr/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/src/php-4.0.6/TSRM
-DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g
-O2   -o libphp4.la -rpath /usr/src/php-4.0.6/libs -avoid-version
-L/usr/local/pgsql/lib  -R /usr/local/pgsql/lib stub.lo  Zend/libZend.la
sapi/apache/libsapi.la main/libmain.la regex/libregex.la
ext/imlib/libimlib.la ext/mysql/libmysql.la ext/pcre/libpcre.la
ext/pgsql/libpgsql.la ext/posix/libposix.la ext/session/libsession.la
ext/standard/libstandard.la ext/xml/libxml.la TSRM/libtsrm.la -lpam -ldl
-lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv
/usr/bin/ld: cannot find -l--library=crypt
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/usr/src/php-4.0.6'
make: *** [all-recursive] Error 1

I also tried adding a couple of paths to the --with-imlib switch, /usr/local/lib and 
/usr/local/include.  Both variations produced the same error as above.

I am trying to "add" imlib support.  This is an upgrade on the same version of PHP I'm 
already running, 4.06.  I experienced no missing crypt libraries on the previous 
install.

I don't exactly understand why it's failing on this error:

/usr/bin/ld: cannot find -l--library=crypt

I don't see any kind of crypt files listed in the requirements for Imlib2: 
http://www.mcclanahan.cx/php_imlib/downloads.php

If I leave off the --with-imlib option I get no errors, so I know that's the part 
that's breaking.

When I installed Imlib2 there were no errors, and I see the files:

> locate Imlib2
/usr/local/lib/libImlib2.so.1.0.1
/usr/local/lib/libImlib2.so.1
/usr/local/lib/libImlib2.so
/usr/local/lib/libImlib2.la
/usr/local/lib/libImlib2.a
/usr/local/include/Imlib2.h

So I had a look at /etc/ld.so.conf.  I added /usr/local/lib and ran ldconfig.  This 
didn't help, same errors as above.

A friend pointed out this:

> -lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv
> ^
> |
> Here's the problem

I have no idea how to fix it, if this is the issue...

I am using

PHP 4.0.6
Apache 1.3.20
MySQL 3.23.40
Postgresql 7.1.2
Imlib2 1.0.1
RedHat 7.1







Edit this bug report at http://bugs.php.net/?id=12563&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e

Re: [PHP-DEV] PHP Extensions: C or C++?

[Jani Taskinen]

On Mon, 6 Aug 2001, David Eriksson wrote:

>(One bug, I believe. But that's one too many of course.)

Ooh..I remembered wrong then. I thought I had seen more..:)
Or I'm thinking of something else. :)

>I do not maintain Satellite any more and Universe is indeed intended to replace
>Satellite.

Cool. I never got Satellite to compile even..

--Jani



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] apache2filter XtOffsetOf' redefined

[Holger Schopohl]

Hi,

i can't compile the current cvs version
with apache 2.0.18.

make[3]: Entering directory 
`/home/schopohl/development/php4/sapi/apache2filter'
/bin/sh /home/schopohl/development/php4/libtool --silent --mode=compile 
/home/schopohl/development/php4/meta_ccld  -I. -
I/home/schopohl/development/php4/sapi/apache2filter -
I/home/schopohl/development/php4/main -I/home/schopohl/development/php4 
-I/usr/local/apache/2.0.18/include -
I/home/schopohl/development/php4/Zend -
I/usr/local/mysql/current/include/mysql -
I/home/schopohl/development/php4/ext/xml/expat  -DNO_DBM_REWRITEMAP -
D_REENTRANT -I../TSRM -I/home/schopohl/development/php4/TSRM -g -O2 -
pthread -prefer-pic  -c sapi_apache2.c
In file included from /usr/local/apache/2.0.18/include/apr_buckets.h:61,
 from /usr/local/apache/2.0.18/include/util_filter.h:59,
 from sapi_apache2.c:33:
/usr/local/apache/2.0.18/include/apr_general.h:115: warning: 
`XtOffsetOf' redefined
/home/schopohl/development/php4/main/php.h:328: warning: this is the 
location of the previous definition
sapi_apache2.c: In function `php_output_filter':
sapi_apache2.c:330: too many arguments to function `ap_save_brigade'
make[3]: *** [sapi_apache2.lo] Error 1

what's wrong?

-- 
Holger

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] apache2filter XtOffsetOf' redefined

[Sebastian Bergmann]

Holger Schopohl wrote:
> i can't compile the current cvs version
> with apache 2.0.18.

  Please upgrade to a recent Apache 2.0 version. It compiles fine
  with httpd-2.0's latest CVS.

-- 
  Sebastian Bergmann Measure Traffic & Usability
  http://sebastian-bergmann.de/http://phpOpenTracker.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Ozgur AKAN
Email: [EMAIL PROTECTED]
ID:ozgurakan
Purpose:   I am a member of php.org.tr and we want to translate the manual to Turskish.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12563 Updated: Imlib2 Issue

[sniper]

ID: 12563
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Closed
Bug Type: Compile Failure
Operating System: RedHat 7.1 / 2.4.7 Kernel
PHP Version: 4.0.6
New Comment:

This indeed was the reason why it didn't work.
The backwards compatibily fix for this AC_* -> PHP_*
conversion didn't really fix it.

It is now fixed in CVS. Quick fix for imlib: change
the AC_ADD_ to PHP_ADD_ in imlib/config.m4 and rerun buildconf.

--Jani


Previous Comments:


[2001-08-06 03:52:22] [EMAIL PROTECTED]

imlib2 uses AC_ADD_LIBRARY and friends instead of PHP_ADD_LIBRARY and friends in it's 
config.m4; it is broken
against CVS, but can be fixed easily.

--Wez.



[2001-08-05 20:20:09] [EMAIL PROTECTED]

The Imlib2 guys say it's a PHP bug:

> I reported what I thought to be a PHP bug, they say it's a bug in Imlib2.
> Please have a look.

I don't see how this can be an imlib2 bug. it's a bug in php's autoconf/make
etc. setup - probably related to how they do imlib2 detection and li checking.

they should use imlib2-config

[- 10:07AM ~ -]imlib2-config --version
1.0.4
[- 10:07AM ~ -]imlib2-config --cflags 
-I/usr/local/include -I/usr/X11R6/include
[- 10:07AM ~ -]imlib2-config --libs  
-L/usr/local/lib -lImlib2 -lttf -lm -ldl -lXext -lXext -lX11 -L/usr/X11R6/lib
[- 10:07AM ~ -]imlib2-config --prefix
/usr/local
[- 10:07AM ~ -]imlib2-config --help
Usage: imlib2-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--libs]
[--cflags]

to figure out cflags and link flags.

this is likely a type.missing character or missing logic statement in their
build procedure. it's not an imlib2 bug - unless your imlib2-config is spewing
out empty results for --libs or --cflags... which it shoudln't.




[2001-08-04 00:19:43] [EMAIL PROTECTED]

Not a PHP bug. Report this to the imlib author instead.




[2001-08-04 00:17:05] [EMAIL PROTECTED]

make fails while trying to add Imlib2 support.

./configure --with-xml --with-apxs=/usr/sbin/apxs --with-mysql=/usr --with-pgsql 
--with-imlib

I can see the configure script finds my new Imlib2 install:


checking for imlib2 support... yes
checking for imlib_load_image in -lImlib2... yes


anyway, here's the error:

Making all in .
make[1]: Entering directory `/usr/src/php-4.0.6'
/bin/sh /usr/src/php-4.0.6/libtool --silent --mode=link gcc  -I.
-I/usr/src/php-4.0.6/ -I/usr/src/php-4.0.6/main -I/usr/src/php-4.0.6
-I/usr/include/apache -I/usr/src/php-4.0.6/Zend -I/usr/include/mysql
-I/usr/src/php-4.0.6/ext/xml/expat/xmltok
-I/usr/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/src/php-4.0.6/TSRM
-DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g
-O2   -o libphp4.la -rpath /usr/src/php-4.0.6/libs -avoid-version
-L/usr/local/pgsql/lib  -R /usr/local/pgsql/lib stub.lo  Zend/libZend.la
sapi/apache/libsapi.la main/libmain.la regex/libregex.la
ext/imlib/libimlib.la ext/mysql/libmysql.la ext/pcre/libpcre.la
ext/pgsql/libpgsql.la ext/posix/libposix.la ext/session/libsession.la
ext/standard/libstandard.la ext/xml/libxml.la TSRM/libtsrm.la -lpam -ldl
-lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv
/usr/bin/ld: cannot find -l--library=crypt
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/usr/src/php-4.0.6'
make: *** [all-recursive] Error 1

I also tried adding a couple of paths to the --with-imlib switch, /usr/local/lib and 
/usr/local/include.  Both variations produced the same error as above.

I am trying to "add" imlib support.  This is an upgrade on the same version of PHP I'm 
already running, 4.06.  I experienced no missing crypt libraries on the previous 
install.

I don't exactly understand why it's failing on this error:

/usr/bin/ld: cannot find -l--library=crypt

I don't see any kind of crypt files listed in the requirements for Imlib2: 
http://www.mcclanahan.cx/php_imlib/downloads.php

If I leave off the --with-imlib option I get no errors, so I know that's the part 
that's breaking.

When I installed Imlib2 there were no errors, and I see the files:

> locate Imlib2
/usr/local/lib/libImlib2.so.1.0.1
/usr/local/lib/libImlib2.so.1
/usr/local/lib/libImlib2.so
/usr/local/lib/libImlib2.la
/usr/local/lib/libImlib2.a
/usr/local/include/Imlib2.h

So I had a look at /etc/ld.so.conf.  I added /usr/local/lib and ran ldconfig.  This 
didn't help, same errors as above.

A friend pointed out this:

> -lpq -lmysqlclient -l -lcrypt -lresolv -lm -ldl -lnsl -lresolv
> ^
> |
> Here's the problem

I have no idea how to fix it, if this is the issue...

I am using

PHP 4.0.

[PHP-DEV] Bug #12587: strange error_reporting(0)-behaviour

[quappe]

From: [EMAIL PROTECTED]
Operating system: Linux (S.u.S.E 6.1)
PHP version:  4.0.6
PHP Bug Type: PHP options/info functions
Bug description:  strange error_reporting(0)-behaviour

hey buglist,

no script necessary...;-)
last friday i installed php4.0.6 (coming from php3.0.17) and found out that
it isn't possible any longer
to suppress a "forgotten ';' parse error" by setting up error_reporting(0)
in my scripts...*sigh*

but if i code a "error_reporting = 0" into the php.ini, those error
(forgotten ';') is suppressed
and cannot be shown again by setting "error_reporting(E_ALL)" in my
script...;-(

is that the intented aim?!

i known about the many, many error-levels and there possibilities, but it
would be nice to have
the chance to suppress or not those trivial errors in my scripts as well,
if desired.

bye,
daniel

-- 
Edit bug report at: http://bugs.php.net/?id=12587&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12588: PHP engine hangs

[laurent . tastet]

From: [EMAIL PROTECTED]
Operating system: NT4.0 SP5
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  PHP engine hangs

I downloaded PHP 4.0.6 binary for win32.

I installed it on IIS4 (which was perfectly working in ASP and PERL mode),
as a CGI module or A ISAPI filter, and in both cases , it crashes IIS
completely after few requests (I need to start again the www service).

I also tried to install this version of PHP as a module for Apache-win32
1.3.20 , and the PHP engine crashed after few requests too..

I 've no error codes in my logs, nothing appears to be wrong in my
php.ini

The db engine used is an access database connected via odbc to the web
site...

please Help, It's going to make me mad :-(

-- 
Edit bug report at: http://bugs.php.net/?id=12588&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12589: juliantojd () returns incorrect JD

[kovi]

From: [EMAIL PROTECTED]
Operating system: Win2K
PHP version:  4.0.5
PHP Bug Type: Calendar related
Bug description:  juliantojd () returns incorrect JD

juliantojd() returns incorrect Julian Days, i.e juliantojd (7,30,2001)
returns 2452134 instead of 2452121. 
See http://www.aavso.org/cdata/jdcalendar.stm 
(But jddayofweek() works well with the proper JD!)
-- 
Edit bug report at: http://bugs.php.net/?id=12589&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12589 Updated: juliantojd () returns incorrect JD

[kovi]

ID: 12589
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Duplicate
Bug Type: Calendar related
Operating System: Win2K
PHP Version: 4.0.5
New Comment:

I was confused with the julian and gregorian calendars...

Previous Comments:


[2001-08-06 07:22:48] [EMAIL PROTECTED]

juliantojd() returns incorrect Julian Days, i.e juliantojd (7,30,2001) returns 2452134 
instead of 2452121. 
See http://www.aavso.org/cdata/jdcalendar.stm 
(But jddayofweek() works well with the proper JD!)





Edit this bug report at http://bugs.php.net/?id=12589&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12589 Updated: juliantojd () returns incorrect JD

[sniper]

ID: 12589
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Duplicate
Status: Bogus
Bug Type: Calendar related
Operating System: Win2K
PHP Version: 4.0.5
New Comment:

user error. :)


Previous Comments:


[2001-08-06 07:28:07] [EMAIL PROTECTED]

I was confused with the julian and gregorian calendars...



[2001-08-06 07:22:48] [EMAIL PROTECTED]

juliantojd() returns incorrect Julian Days, i.e juliantojd (7,30,2001) returns 2452134 
instead of 2452121. 
See http://www.aavso.org/cdata/jdcalendar.stm 
(But jddayofweek() works well with the proper JD!)





Edit this bug report at http://bugs.php.net/?id=12589&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12498 Updated: cant config magic_quotes_off

[sniper]

ID: 12498
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Configuration Issues
Operating System: Windows 4.9 (Me)
PHP Version: 4.0.6
New Comment:

Are you running PHP in CGI mode? Or as apache module?
And have you read the install.txt file? It says where
you should put php.ini in your system.

--Jani


Previous Comments:


[2001-07-31 22:35:36] [EMAIL PROTECTED]

Hi I have installed 4.0.6 and have had no major problems it seems however That I can't 
change the config from the compiled in data, i.e. I have installed Ariadne, and it 
requires magic_guotes_gpc to be 'off' so I modified the php.ini in the windows dir to 
set magic_quotes_gpc to be off but then php crashes, and wont recognise any php 
script, as in 
'Warning: Failed opening '/apache/htdocs/phpinfo.php' for inclusion 
(include_path='.;c:\apache\php\includes;c:\apache\includes;c:\apache\htdocs') in 
Unknown on line 0'

any help would be appreciated as I need to run Ariadne locally during development.

n.b. if I remove php.ini from the windows dir, phpinfo.php runs (as does everything 
else Php wise) and phpinfo states that the php.ini file is in c:\winnt which of course 
it isn't???

Sincerely yours

George R Wood.






Edit this bug report at http://bugs.php.net/?id=12498&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12590: hex const (0xABCDEF01) parsing error

[vda]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.5
PHP Bug Type: Scripting Engine problem
Bug description:  hex const (0xABCDEF01) parsing error

Looks like there's some trouble with parsing big hex consts
(those with sign bit set). Try this:
...
echo (0x7FFF00FF & 0x); //echoes 255
echo (0x80FF & 0x); //echoes 0!!!
...
0x80FF apparently is mis-parsed.
-- 
Edit bug report at: http://bugs.php.net/?id=12590&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12502 Updated: oci8.dll can't be loaded

[sniper]

ID: 12502
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: OCI8 related
Operating System: WinNT and Windows 2000
PHP Version: 4.0.6
New Comment:

Ask support questions on the appropriate mailing list:

http://www.php.net/support.php

( php-db / php-windows ) after you have searched the
archives, of course.

--Jani


Previous Comments:


[2001-08-02 11:57:23] [EMAIL PROTECTED]

sorry ORACLE VERSION 8.05



[2001-08-02 11:56:00] [EMAIL PROTECTED]

I found in the faqs the following (exactly the same problem)

"This problem was also seen under the ODBC drivers for Windows.  The solution so far 
has
been to remove all Windows based carriage returns (\r\n) in your TNSNames.ora and
SQLNet.ora file, and replace them with unix style carriage returns (\n).

This should end your problem.  Why is this happening?  It's unknown at the time, but 
is
being investigated.  
"

I convert this 2 files to Unix format (only \n) but the problem still happend.

any help?



[2001-08-01 21:54:15] [EMAIL PROTECTED]

Sniper,

I change my php.ini 

I comment php_oci8.dll
and uncomment php_oracle.dll

This work.

But now I recieve the following problem:

TNS:could not resolve service name 

I try with 

$db= ora_logon("demo_user/demo_password@demo","");

This TNS exist and the user and the password too.

(this is the right place for this question?)

thank you again.



[2001-08-01 15:58:57] [EMAIL PROTECTED]

I don't understand this program.
Please check this image :

http://www.netred.cl/php.jpg

(image of my screen).




[2001-08-01 10:20:42] [EMAIL PROTECTED]

to look on which external dlls an exe or an dll is relying you can use the dependency 
walker - 
http://www.dependencywalker.com/




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=12502


Edit this bug report at http://bugs.php.net/?id=12502&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12591: php -l doesn't output anything

[kame]

From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version:  4.0.6
PHP Bug Type: PHP options/info functions
Bug description:  php -l doesn't output anything

under windows, in the php.exe directory :
php -l php.exe, no output, no complain, you can try with whatever you want,
either good or bad php, binary or text file. PHP.net windows zip.
-- 
Edit bug report at: http://bugs.php.net/?id=12591&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12591 Updated: php -l doesn't output anything

[sniper]

ID: 12591
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: PHP options/info functions
Operating System: Windows 98
PHP Version: 4.0.6
New Comment:

This should be fixed in CVS.
Try a snapshot:

http://www.zend.com/snapshots/

--Jani

Previous Comments:


[2001-08-06 07:39:20] [EMAIL PROTECTED]

under windows, in the php.exe directory :
php -l php.exe, no output, no complain, you can try with whatever you want, either 
good or bad php, binary or text file. PHP.net windows zip.





Edit this bug report at http://bugs.php.net/?id=12591&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12555 Updated: imap_body on empty messages causes seg fault

[sniper]

ID: 12555
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: IMAP related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

I can not reproduce this with PHP 4.0.6. 
With which c-client version is your PHP linked with?

--Jani


Previous Comments:


[2001-08-03 12:08:10] [EMAIL PROTECTED]

After opening an imap connection, calling imap_body for a message which is has an 
empty body will cause the apache server to seg fault (11). This caused several 
problems as on some of our accounts the first message was empty (for other reasons) 
and so any php imap client would fail immediately on loading. We have fixed this by 
testing for message size - but the imap_body code should probably spot this.

Thanks,

Jon.





Edit this bug report at http://bugs.php.net/?id=12555&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] apache2filter XtOffsetOf' redefined

[Holger Schopohl]

In article <[EMAIL PROTECTED]>, sb@sebastian-
bergmann.de says...
> Holger Schopohl wrote:
> > i can't compile the current cvs version
> > with apache 2.0.18.
> 
>   Please upgrade to a recent Apache 2.0 version. It compiles fine
>   with httpd-2.0's latest CVS.

okay, that works fine, thanks.

someone has wrote in sapi/apache2filter/README, that
i must only write


SetOutputFilter PHP
SetInputFilter PHP


is it all? no "AddType" ?
my apache parse no .php file...

-- 
Holger

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] apache2filter XtOffsetOf' redefined

[Sebastian Bergmann]

Holger Schopohl wrote:
> 
> SetOutputFilter PHP
> SetInputFilter PHP
> 
> 
> is it all? no "AddType" ?

  This is correct. PHP registers itself as a filter with Apache 2.

> my apache parse no .php file...

  It works. At least on my and Sascha's machines :-)

-- 
  Sebastian Bergmann Measure Traffic & Usability
  http://sebastian-bergmann.de/http://phpOpenTracker.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RES: Bug #12471 Updated: DCOM don't running

[Ismael da Silva Mendes]

  Hi, I'm brasilian this is o code i'm try running!!



  Teste PHP & COM


"Teste PHP & COM/DCOM"
Escreve_texto("Terrible");

echo "$text";

?>



  This too is my php.ini!!!


[Sockets]
sockets.use_system_read=On  ; Use the system read() function instead of
; the php_read() wrapper.

; Local Variables:
; tab-width: 4
; End:
;com.typelib_file = 

com.allow_dcom = on

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: Bug #12536 Updated: fread does not look to be working right

[Andy]

4.0.6 is stable

get it at http://php.net/downloads.php

On Sun, 05 Aug 2001, knight wrote:
> I have not tried it with the 4.0.6 php, is that a stable version yet???
> 
> Can I use the ms 6.0 compiler to compile php? Does it matter what compiler I
> use?? What compiler do you recommend?
> 
> I will update the message with a example
> 
> Brendan Ferguson
> 
> -Original Message-
> From: Bug Database [mailto:[EMAIL PROTECTED]]
> Sent: August 2, 2001 5:38 PM
> To: [EMAIL PROTECTED]
> Subject: Bug #12536 Updated: fread does not look to be working right
> 
> ID: 12536
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: Performance problem
> Operating System: win 98 box
> PHP Version: 4.0.4pl1
> New Comment:
> 
> Have you tried with PHP 4.0.6? And could you also
> add a short example script into this bug report?
> 
> --Jani
> 
> 
> Previous Comments:
> 
> 
> [2001-08-02 17:34:06] [EMAIL PROTECTED]
> 
> fread does not look like it is reading the EOF. when i use a large (HUDGE)
> number to tell the fread() how many characters to read, it takes a  l o n g
> time for this to complete this happens even when the file is very short.
> 
> i descoverd this when i was trying to read an entire file into a string. is
> fread the best way to do this?? it does not seem to be working very well.
> 
> there is also a error reporting problem with fread. after the same number
> gets too big, php stops processing the entire page, (it does check syntax)
> there is als no error message when this happens.
> 
> Knight
> 
> 
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
> http://bugs.php.net/?id=12536&edit=2
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11976 Updated: image_copy_resized does not work properly

[sniper]

ID: 11976
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: GD related
Operating System: windows 98 SE
PHP Version: 4.0.6
New Comment:

With GD 2.0.1 -> No workie.
With GD 1.8.4 -> Works fine. 

Not a bug in PHP but in the (beta) GD 2.0.1.

--Jani

(Why was the windows module compiled with beta-GD??)


Previous Comments:


[2001-07-24 08:50:54] [EMAIL PROTECTED]

exactly the result I got.  Can anybody else reproduce this?

I still think this is bogus.



[2001-07-24 03:08:00] [EMAIL PROTECTED]

The image result supposed to be a png image like this:

---|-
 | |  | |  | |  | |  | |   |
 | |  | |   -   | |  | |   |
 | |   -| |  | |   |
  -  -   | |   |
  -|
   |
   |

So it is supposed to be a graph with blue rectangles and two black lines, not a black 
square.



[2001-07-23 11:43:58] [EMAIL PROTECTED]

My script should not draw a black image but a blue graph( blue rectangles).
Actually, with php4.0.6, my script draw a black square and with php4.0.5 my script 
draw a graphics with blue rectangles.
It works with php4.0.6 only if I don't use the function image_copy_resized. So In 
conclusion, I think that there is a problem with this function on php4.0.6 with W98 
OS??



[2001-07-23 09:33:38] [EMAIL PROTECTED]

so what is the problem.  The image works now...  Just make sure
you set the header to "image/png" or whatever file type
the image is.



[2001-07-23 06:24:34] [EMAIL PROTECTED]

When I removed the header function (or set it to "text/html"), I have this on my 
browser:
" PNG "??
If I keept "image/png" or "image/jpeg", I have a all-in black image??  



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=11976


Edit this bug report at http://bugs.php.net/?id=11976&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12349 Updated: Broken PNG image

[sniper]

ID: 12349
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: GD related
Operating System: Windows 98
PHP Version: 4.0.6
New Comment:

This is a bug in the GD-2.0.1 (beta) library.
Closed.

--Jani


Previous Comments:


[2001-07-25 03:47:46] [EMAIL PROTECTED]

I use standart version of PHP, downloaded from www.php.net

i think in PHP 4.0.5 and 4.0.6 used GD 1.8.4
but in PHP 4.0.6 ChangeLog file i see some GD 2.0.1 function



[2001-07-24 21:45:02] [EMAIL PROTECTED]

Which version of GD do you have?



[2001-07-24 21:43:36] [EMAIL PROTECTED]

No, only with PNG, with JPG format working fine,
and i dont install GIF support, only standart installation of PHP 4.0.6

And - i copy php_gd.dll from PHP 4.0.5 in to PHP 4.0.6 directory - CopyResized 
working, but some GD function not working - PHP crashed.

PS Sorry for bad english, im living in Ukraine and dont have big language practic



[2001-07-24 17:39:23] [EMAIL PROTECTED]

does this happen with jpgs or gifs (if you have support for
gifs)?



[2001-07-24 14:33:30] [EMAIL PROTECTED]

i have problem with create small copy of PNG transparent images:

Windows 98
apache 1.3.20
php 4.0.6

$s[1])
$z = $s[0]/60;
else
$z = $s[1]/60;
$x = (int)($s[0]/$z);
$y = (int)($s[1]/$z);
$dst_img = ImageCreate($x,$y);
$src_img = ImageCreateFromPNG("../img/test.png");
$colT = ImageColorAllocate($dst_img,0,255,0);
ImageFill($dst_img,0,0,$colT);
ImageCopyResized($dst_img,$src_img,0,0,0,0,$x,$y,$s[0],$s[1]);
ImageColorTransparent($dst_img,$colT);
ImagePNG($dst_img);
ImageDestroy($src_img);
ImageDestroy($dst_img);
?>

and i have broken fullcolored rectangle

BUT - with php 4.0.5 work all best





Edit this bug report at http://bugs.php.net/?id=12349&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #12581 Updated: boolean fields not imported (patches enclosed)

[Andy]

I didn't think that opening a bug report just to
put a patch in it was correct.  Patches are
supposed to be sent to the php-dev mailing list.

Was I wrong?

On Sun, 05 Aug 2001, Jani Taskinen wrote:
> Could you please tell me what is the 'Bogus' in this report?
> It's a bug report which happens to have a patch for the bug too.
> This is far from bogus report. Reopened.
> 
> --Jani
> 
> 
> On 5 Aug 2001 [EMAIL PROTECTED] wrote:
> 
> >ID: 12581
> >Updated by: andy
> >Reported By: [EMAIL PROTECTED]
> >Old Status: Open
> >Status: Bogus
> >Bug Type: dBase related
> >Operating System: Linux 2.2.16-3
> >PHP Version: 4.0.6
> >New Comment:
> >
> >status -> bogus
> >
> >Previous Comments:
> >
> >
> >[2001-08-05 16:18:03] [EMAIL PROTECTED]
> >
> >this is not a bug...already forwarded to [EMAIL PROTECTED]
> >
> >Thanks for your help, but next time just send it to [EMAIL PROTECTED]
> >and don't open a bug about it.
> >
> >
> >
> >[2001-08-05 16:17:47] [EMAIL PROTECTED]
> >
> >The file name to which the patches apply is ext/dbase/dbase.c.
> >
> >
> >
> >[2001-08-05 16:16:32] [EMAIL PROTECTED]
> >
> >Below are patches that fix the problem reported 10/20/2000 in bug report #7374.  
>The problem is that when boolean (TRUE or FALSE) fields are present in an imported 
>Dbase file, the value is always imported as FALSE (0).  This problem has been present 
>since 4.0.3.  The patches below were generated using distribution 4.0.6.
> >
> >466,467c466
> >< case 'N':   /* FALLS THROUGH */
> >< case 'L':   /* FALLS THROUGH */
> >---
> >> case 'N':
> >473a473,486
> >> case 'L':   /* we used to FALLS THROUGH, but now we check for T/Y and F/N
> >>and insert 1 or 0, respectively.  db_fdc is the number of
> >>decimals, which we don't care about.  3/14/01 LEW */
> >>   if ( (*str_value == 'T') || ( *str_value == 'Y' ) ){
> >>   add_next_index_long(return_value, strtol("1", NULL, 10));
> >>   } else {
> >> if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
> >>   add_next_index_long(return_value, strtol("0", NULL, 10));
> >> }
> >> else {
> >>   add_next_index_long(return_value, strtol(" ", NULL, 10));
> >>  }
> >>   }
> >>   break;
> >544,545c557
> ><   case 'N':   /* FALLS THROUGH */
> ><   case 'L':   /* FALLS THROUGH */
> >---
> >>   case 'N':
> >551a564,578
> >>   case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
> >>and insert 1 or 0, respectively.  db_fdc is the number of
> >>decimals, which we don't care about.  3/14/01 LEW */
> >> if ( (*str_value == 'T') || ( *str_value == 'Y') ){
> >> add_assoc_long(return_value, cur_f->db_fname, strtol("1", 
>NULL, 10));
> >> } else {
> >>   if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
> >>   add_assoc_long(return_value, cur_f->db_fname,strtol("0", 
>NULL, 10));
> >>}
> >> else {
> >>   add_assoc_long(return_value, cur_f->db_fname,strtol(" ", 
>NULL, 10));
> >>  }
> >> }
> >> break;
> >>
> >
> >
> >
> >
> >
> >
> >Edit this bug report at http://bugs.php.net/?id=12581&edit=1
> >
> >
> >

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12555 Updated: imap_body on empty messages causes seg fault

[jon]

ID: 12555
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: IMAP related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

The version linked to from the documentation pages (4.7 i believe) - though I have 
tried others (regressing back). I am minded that this 'could' be a very isolated error 
caused by the imap mailbox containing 0 byte files (which clearly would not happen 
very often). If this is the case, contact me for details of how to access an account 
with these 0byte files.

Thanks,

Previous Comments:


[2001-08-06 07:51:14] [EMAIL PROTECTED]

I can not reproduce this with PHP 4.0.6. 
With which c-client version is your PHP linked with?

--Jani




[2001-08-03 12:08:10] [EMAIL PROTECTED]

After opening an imap connection, calling imap_body for a message which is has an 
empty body will cause the apache server to seg fault (11). This caused several 
problems as on some of our accounts the first message was empty (for other reasons) 
and so any php imap client would fail immediately on loading. We have fixed this by 
testing for message size - but the imap_body code should probably spot this.

Thanks,

Jon.





Edit this bug report at http://bugs.php.net/?id=12555&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12593: Serious Ouput Problem in tag

[tcmleung]

From: [EMAIL PROTECTED]
Operating system: Window 2000 server with IIS
PHP version:  4.0.6
PHP Bug Type: Session related
Bug description:  Serious Ouput Problem in  tag

The session_register() seems accessing wrong memory address and causing
some strange bugs.
The following phtml shows the bugs. Please run it and see the ouput of the
source code from Internet Explorer.

--
--











apple
banana
pear
orange
water-melon
sweet-melon








---
---

Here is the source output from internet explorer:







It is a serious bug.


apple
banana

< onchange='' onKeyPress='return fncNoEnt(event)'>pear
orange
water-melon
sweet-melon





 

-- 
Edit bug report at: http://bugs.php.net/?id=12593&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9639 Updated: Nasty bug in mod_mm.c causes CGI POST to stop working

[sniper]

ID: 9639
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: Red Hat
PHP Version: 4.0.4pl1
New Comment:

Please create this patch against the latest CVS.
And put it somewhere in the net to be downloaded and
add the url here.

--Jani


Previous Comments:


[2001-06-27 11:31:29] [EMAIL PROTECTED]

Does this happen with 4.0.6 (now that is released) ?

--Jani




[2001-06-14 23:27:47] [EMAIL PROTECTED]

Does this still happen with PHP 4.0.6RC3:

http://www.php.net/~andi/php-4.0.6RC3.tar.gz

If above link does not work, change RC3 to RC4.

--Jani




[2001-03-08 17:10:21] [EMAIL PROTECTED]

On RedHat 6.2 or 7 machine with more than 67M of shared memory available
per process (this number is stored in /proc/sys/kernel/shmmax)
Compile Apache with ssl modules.
Compile mod_php into Apache --with-mm

Have 3300 ( or anything less than 67M) in /proc/sys/kernel/shmmax on
machine where you're running Apache -> CGI POST stops working, stdin is
empty. This happens regardless of what kind of cgi script is executted
by the form, it doesn't have to be a php script. Increase the number in
/proc/sys/kernel/shmmax to something more than 67M, everything works
again. This 67M number is hardcoded in mm_create from mm library by
their configure script, which checks how much memory is available.
I have no explanation for it, because all mod_mm does in this case is
returning FAILURE if there is not enough memory. Go figure...
Here is my proposal: lets check how much memory is there before calling
mm_create in mod_mm.c by doing this: (I put the actual patch at the
bottom)

Add two new functions ( pretty much copied from mm configure)

static int test_mem_size (unsigned long size)
{
int fd;
void *segment;
#ifdef MM_SHMT_MMFILE
char file[] = "./ac_test.tmp";
unlink(file);
if ((fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1)
return 0;
if (ftruncate(fd, size) == -1)
return 0;
if ((segment = (void *)mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_SHARED, fd, 0)) == MAP_FAILED) {
close(fd);
return 0;
}
munmap((caddr_t)segment, size);
close(fd);
unlink(file);
#endif
#ifdef MM_SHMT_IPCSHM
if ((fd = shmget(IPC_PRIVATE, size, SHM_R|SHM_W|IPC_CREAT)) == -1)
return 0;
if ((segment = (void *)shmat(fd, NULL, 0)) == ((void *)-1)) {
shmctl(fd, IPC_RMID, NULL);
return 0;
}
shmdt(segment);
shmctl(fd, IPC_RMID, NULL);
#endif
return 1;
}
#define ABS(n) ((n) >= 0 ? (n) : (-(n)))

static unsigned long get_max_mem_size()
{
  unsigned long t, m, b;
int d;
int rc;
/*
 * Find maximum possible allocation size by performing a
 * binary search starting with a search space between 0 and
 * 64MB of memory.
 */
t = 1024*1024*64 /* = 67108864 */;
if (test_mem_size(t))
m = t;
else {
m = 1024*1024*32;
b = 0;
for (;;) {
/* fprintf(stderr, "t=%d, m=%d, b=%d\n", t, m, b); */
rc = test_mem_size(m);
if (rc) {
d = ((t-m)/2);
b = m;
}
else {
d = -((m-b)/2);
t = m;
}
if (ABS(d) < 1024*1) {
if (!rc)
m = b;
break;
}
if (m < 1024*8)
break;
m += d;
}
if (m < 1024*8)
m = 0;
}
return m;
}

The actual patch would look like this:

--- ext/session/mod_mm.c Fri Nov  3 07:00:49 2000
+++ ext/session/mod_mm.c Tue Feb 27 14:09:31 2001
@@ -173,9 +173,84 @@

 #define PS_MM_DATA ps_mm *data = PS_GET_MOD_DATA()

+static int test_mem_size (unsigned long size)
+{
+int fd;
+void *segment;
+#ifdef MM_SHMT_MMFILE
+char file[] = "./ac_test.tmp";
+unlink(file);
+if ((fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1)
+return 0;
+if (ftruncate(fd, size) == -1)
+return 0;
+if ((segment = (void *)mmap(NULL, size, PROT_READ|PROT_WRITE,
+MAP_SHARED, fd, 0)) == MAP_FAILED) {
+close(fd);
+return 0;
+}
+munmap((caddr_t)segment, size);
+close(fd);
+unlink(file);
+#endif
+#ifdef MM_SHMT_IPCSHM
+if ((fd = shmget(IPC_PRIVATE, size, SHM_R|SHM_W|IPC_CREAT)) == -1)
+return 0;
+if ((segment = (void *)shmat(fd, NULL, 0)) == ((void *)-1)) {
+shmctl(fd, IPC_RMID, NULL);
+return 0;
+}
+shmdt(segment);
+shmctl(fd, IPC_RMID, NULL);
+#endif

[PHP-DEV] Bug #11976 Updated: image_copy_resized does not work properly

[rasmus]

ID: 11976
Updated by: rasmus
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: GD related
Operating System: windows 98 SE
PHP Version: 4.0.6
New Comment:

Because GD2 is overall much much better than GD 1.x despite the fact that they are 
still labelling it a beta.  And yes, there may still be the odd bug or two.  In this 
particular case if you use imagecreatetruecolor() instead of imagecreate() it works 
fine.  And since you are generating a PNG image you should be using 
imagecreatetruecolor() anyway.  

To the original person who reported this, try asking the GD folks about this problem.

Previous Comments:


[2001-08-06 08:33:26] [EMAIL PROTECTED]

With GD 2.0.1 -> No workie.
With GD 1.8.4 -> Works fine. 

Not a bug in PHP but in the (beta) GD 2.0.1.

--Jani

(Why was the windows module compiled with beta-GD??)




[2001-07-24 08:50:54] [EMAIL PROTECTED]

exactly the result I got.  Can anybody else reproduce this?

I still think this is bogus.



[2001-07-24 03:08:00] [EMAIL PROTECTED]

The image result supposed to be a png image like this:

---|-
 | |  | |  | |  | |  | |   |
 | |  | |   -   | |  | |   |
 | |   -| |  | |   |
  -  -   | |   |
  -|
   |
   |

So it is supposed to be a graph with blue rectangles and two black lines, not a black 
square.



[2001-07-23 11:43:58] [EMAIL PROTECTED]

My script should not draw a black image but a blue graph( blue rectangles).
Actually, with php4.0.6, my script draw a black square and with php4.0.5 my script 
draw a graphics with blue rectangles.
It works with php4.0.6 only if I don't use the function image_copy_resized. So In 
conclusion, I think that there is a problem with this function on php4.0.6 with W98 
OS??



[2001-07-23 09:33:38] [EMAIL PROTECTED]

so what is the problem.  The image works now...  Just make sure
you set the header to "image/png" or whatever file type
the image is.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=11976


Edit this bug report at http://bugs.php.net/?id=11976&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10833 Updated: Hyperlink tag when split on multiple lines, session ids are not propagated

[sniper]

ID: 10833
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0.5
New Comment:

No feedback. And the latest CVS works just fine
on this kind of urls.

--Jani


Previous Comments:


[2001-07-10 05:05:45] [EMAIL PROTECTED]

Could you give a snapshot a try?

http://snaps.php.net/

The scanner is supposed to ignore whitespace.



[2001-05-12 17:24:31] [EMAIL PROTECTED]

This applicable for browsers that don't allow cookies:

The following is not working:
">
Menu 

But if href is on the same line as  tag, it works:
">
Menu 







Edit this bug report at http://bugs.php.net/?id=10833&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12594: Unable to load dynamic library

[huib]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.6
PHP Bug Type: Dynamic loading
Bug description:  Unable to load dynamic library 

I'm recieve the following error:
Unable to load dynamic library 

for the extensions:
libmcrypt.dll
php_mssql.dll

Some other extensions work fine.
php_mssql.dll is included with php 4.0.6 and libmcrypt is downloaded from a
link at php.net

so help me out please,

Regards Huib
-- 
Edit bug report at: http://bugs.php.net/?id=12594&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12595: $argv passing

[sorgo]

From: [EMAIL PROTECTED]
Operating system: win2k (prob. all win\'s)
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  $argv passing

When installing php on win32 it creates a registry record at "My
Computer\HKEY_CLASSES_ROOT\Applications\" named php.exe

the problem is that the value of "My
Computer\HKEY_CLASSES_ROOT\Applications\php.exe\shell\open\command\" is
default 'C:\php\php.exe "%1"' it means it only passes to php.exe the first
argument = the name of the file and it do NOT pass any other arguments.

The solution is (maybe can be in a newer version of win32 php) to set the
value to 'C:\php\php.exe -q "%1" %2 %3 %4 %5 %6 %7 %8 %9'

(maybe without the -q argument)

Sorgo
-- 
Edit bug report at: http://bugs.php.net/?id=12595&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10895 Updated: Segmentation Fault

[andy]

ID: 10895
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Session related
Operating System: Sun Solaris 5.8 on Intel
PHP Version: 4.0.5
New Comment:

no feedback

Previous Comments:


[2001-06-14 23:42:56] [EMAIL PROTECTED]

We need a GDB backtrace of the crash, otherwise it is
impossible to know what causes it.

First get the latest RC from here:

http://www.php.net/~andi/php-4.0.6RC3.tar.gz

If above link doesn't work, try with RC4.

Then configure it using same options as before but change
the --disable-debug to --enable-debug otherwise the result
of GDB is useless.





[2001-05-16 04:02:52] [EMAIL PROTECTED]

I had got Segmentation Faults using the sessions with PHP 4.05. After installing PHP 
4.04pl1 the same code works fine.

I use the session_start(),session_register(),session_unregister() functions. But i 
could not localize which of them causes the problems, i'd expect that it is 
session_unregister().

"./configure" \
"--with-mysql=/usr/local/mysql" \
"--with-apache=../apache_1.3.19" \
"--enable-dbg=shared" \
"--with-ttf=/usr/local" \
"--with-gd" \
"--with-xml" \
"--with-zlib=/usr/local" \
"--with-jpeg-dir=/usr/local" \
"--enable-track-vars" \
"--enable-url-includes" \
"--disable-debug" \

Claus





Edit this bug report at http://bugs.php.net/?id=10895&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10955 Updated: session configured with session_set_save_handler and a database

[andy]

ID: 10955
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Session related
Operating System: Red Hat Linux release 6.2 (Zoot)
PHP Version: 4.0.5
New Comment:

no feedback

Previous Comments:


[2001-06-12 16:23:32] [EMAIL PROTECTED]

any chance you can try one of the latest RCs for 4.0.6?

There was an update for the set_save function done recently I believe.



[2001-05-18 11:08:06] [EMAIL PROTECTED]

The problem is that when i'm using session_set_save_handler to store session data on 
an oracle base with php4.0.5, the 'write' function is never called, whereas on a 
4.0.4pl1 it works fine !

The 4.0.4pl1 PHP (the good one) is running on a 2000 system, with the same php.ini as 
below


php4.0.5 (the bad one ?) was installed on a linux like this:
Configure Command: './configure' '--with-oci8' '--with-apache=../apache_1.3.19' 
'--enable-track-vars'

with this php.ini:

[PHP]

;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior.  In order for PHP to
; read it, it must be named 'php.ini'.  PHP looks for it in the current
; working directory, in the path designated by the environment variable
; PHPRC, and in the path that was defined in compile time (in that order).
; Under Windows, the compile-time path is the Windows directory.  The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple.  Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and parentheses:
; | bitwise OR
; & bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after the equal
; sign, or by using the None keyword:
;
;   foo =   ; sets foo to an empty string
;   foo = none  ; sets foo to an empty string
;   foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a dynamically
; loaded extension (either a PHP extension or a Zend extension), you may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these lines,
; the builtin defaults will be identical).



; Language Options ;


engine  =   On  ; Enable the PHP scripting language engine 
under Apache
short_open_tag  =   On  ; allow the  tags are recognized.
asp_tags=   Off ; allow ASP-style <% %> tags
precision   =   14  ; number of significant digits displayed in 
floating point numbers
y2k_compliance  =   Off ; whether to be year 2000 compliant (will cause 
problems with non y2k compliant browsers)
output_buffering= Off   ; Output buffering allows you to send header lines 
(including cookies)
; even after you send body 
content, in the price of slowing PHP's
; output layer a bit.
; You can enable output 
buffering by in runtime by calling the output
; buffering functions, or 
enable output buffering for all files
; by setting this directive to 
On.
output_handler  =   ; You can redirect all of the output of your 
scripts to a function,
; that can be responsible to 
process or log it.  For example,
; if you set the 
output_handler to "ob_gzhandler", than output
  

[PHP-DEV] Bug #11573 Updated: Malformed HTTP response Header

[andy]

ID: 11573
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0.5
New Comment:

no feedback

Previous Comments:


[2001-06-20 12:04:09] [EMAIL PROTECTED]

Which broswser and what version of it? 
Please include a short but complete not working script into
this report.

--Jani




[2001-06-20 05:04:48] [EMAIL PROTECTED]

I'm using the session*() functions and test them with a browser which refuses cookies. 
So I add "PHPSESSID=." as a parameter of the requested url.

For example, I call "qcmcreate.php?parm1=xxx&parm2=yyy&PHPSESSID=z". I noticed 
that the HTTP header returned by my script contain an extra line that confuses my 
client.

The end of the HTTP header looks like:

Content-Type: test/html
\r\n
\r\n
xxx
\r\n
\r\n

(\r\n means a "blank and empty line")
What's wrong here are the "xxx\r\n\r\n" lines. Where "xxx" is up to 3 characters. 
These 3 lines make my client misinterpret the server response.

If I make my browser accept cookies, the problem disappears.

To make sure I did not echo anything, the 1st instruction of my "qcmcreate.php" script 
is "die;"

What's wrong ?

Thank you,

Jerome
Pl





Edit this bug report at http://bugs.php.net/?id=11573&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11883 Updated: unmotivated memory exhausting

[andy]

ID: 11883
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux Kernel 2.2.16
PHP Version: 4.0.6
New Comment:

no feedback

Previous Comments:


[2001-07-04 14:30:24] [EMAIL PROTECTED]

Please try the patch found at:

http://www.php.net/do_download.php?download_file=php-4.0.6-memlimit.diff.gz&source_site=www.php.net






[2001-07-04 13:47:36] [EMAIL PROTECTED]

using apache with php-module v4.0.6, mysql3.23.35; configure:
'./configure' '--with-apxs=/virtual/development/httpd/bin/apxs' '--without-debug' 
'--with-config-file-path=/virtual/development/httpd/conf' '--enable-sysvsem' 
'--enable-sysvshm' '--enable-shmop' '--with-ftp' '--enable-track-vars=yes' 
'--enable-gd-native-ttf' '--enable-memory-limit=yes' '--enable-magic-quotes=yes' 
'--enable-trans-sid=yes' '--enable-inline-optimization' 
'--with-mysql=/usr/local/mysql' '--with-ttf=/usr/lib/freetype2' '--with-zlib' 
'--enable-calendar' '--with-jpeg-dir=/usr/local/lib' '--with-pnglib=/usr/local/lib' 
'--with-gd' '--enable-sockets'


we had no problems at all with 4.0.5, but since we have 4.0.6 on our server, 
we get unmotivated "memory exhausting at any script on any line".
the error does not occure regularly, but when it happens, it comes many times in a 
row, just like php needs a bit of time to eat the memory, then crashes multiple times, 
and finally finds peace for a few hours working correctly. till the next day or so.
I can't give you a code-snippet to reproduce it, because when the error occurs, you 
can simply reload the page and most of the times it then works, but only most of the 
times...









Edit this bug report at http://bugs.php.net/?id=11883&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11914 Updated: Segmentation fault on Apache 1.3.20/1.3.19

[andy]

ID: 11914
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Apache related
Operating System: SuSE 7.0
PHP Version: 4.0.6
New Comment:

no feedback

Previous Comments:


[2001-07-06 03:28:38] [EMAIL PROTECTED]

What is your configure line? (To both Apache and PHP)

Derick



[2001-07-05 15:50:29] [EMAIL PROTECTED]


I was installing PHP support on my Apache 1.3.19 as Static Module, when 
after I done the
steps for installing and starting Apache daemon I was the following error 
messages on
apache's log:

[Thu Jul  5 15:44:43 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.6 
configured -- resuming
normal operations
[Thu Jul  5 15:45:31 2001] [notice] child pid 24328 exit signal 
Segmentation fault (11)
[Thu Jul  5 15:45:34 2001] [notice] child pid 24327 exit signal 
Segmentation fault (11)

And all requests I did to my webserver I received that messages and 
nothing was returned
back to my browser

After some tries to compile with different apache versions, I tried to 
compile a different
PHP version, 3.0.5, with my Apache on Static Mode, and I got it!

I don't know what is going on with PHP/4.0.6, but I couldn't install with 
Apache/1.3.20 on
a SuSE 7.0

p.s. - I tried once a installation as Dynamic Module and I hadn't sucessful too.
p.s. 2 - I used the following parameters to configure PHP, other parameters were 
default:
./configure --with-pgsql=/usr/lib/pgsql/ --with-apache=../apache_1.3.20
--enable-track-vars



[2001-07-05 15:38:30] [EMAIL PROTECTED]


I was installing PHP support on my Apache 1.3.19 as Static Module, when after I done 
the steps for installing and starting Apache daemon I was the following error messages 
on apache's log:

[Thu Jul  5 15:44:43 2001] [notice] Apache/1.3.20 (Unix) PHP/4.0.6 configured -- 
resuming normal operations
[Thu Jul  5 15:45:31 2001] [notice] child pid 24328 exit signal Segmentation fault 
(11)
[Thu Jul  5 15:45:34 2001] [notice] child pid 24327 exit signal Segmentation fault 
(11)

And all requests I did to my webserver I received that messages and nothing was 
returned back to my browser

After some tries to compile with different apache versions, I tried to compile a 
different PHP version, 3.0.5, with my Apache on Static Mode, and I got it!

I don't know what is going on with PHP/4.0.6, but I couldn't install with 
Apache/1.3.20 on a SuSE 7.0

p.s. I tried once a installation as Dynamic Module and I hadn't sucessful too.





Edit this bug report at http://bugs.php.net/?id=11914&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11951 Updated: HTML encoding problem

[andy]

ID: 11951
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Unknown/Other Function
Operating System: Any
PHP Version: 4.0.5
New Comment:

no feedback

Previous Comments:


[2001-07-07 19:52:59] [EMAIL PROTECTED]

Have you checked the default_charset in your php.ini?



[2001-07-07 18:18:16] [EMAIL PROTECTED]

There definately seems to be a problem using any operating system I've tried (Linux 
Debian, RedHat, Windows 98, Windows 2000). The problem is that the following piece of 
HTML:
http://www.w3.org/TR/html4/loose.dtd";>



...

will somehow be ignored, i.e. the document will not have this encoding set, instead 
ISO-8859-1 will be used. The biggest problem is that if try to change the encoding in 
the browser it won't change it, even though the browser will show it changed or if it 
changes it (very rare), after you reload the page the encoding is set back to 
ISO-8859-1, even though the browser always shows that the encoding is changed. This 
happens for all files that are processed by the php engine. I've correctly set the 
encoding option in the php.ini, even though it is always best for php, not to set this 
at all, since if you're using a remote server, for example hosting you site in the 
USA, but the page is in cyrillic, your php pages will never display properly. Probably 
the best thing is to leave the encoding up to the HTML headers set by each page.

My workaround for this problem is (it always works correctly):

http://www.w3.org/TR/html4/loose.dtd";>





where set_encoding.inc, contains in my case the following:
  header("Content-type: text/html;charset=windows-1251");
  header("Content-Language: bg");







Edit this bug report at http://bugs.php.net/?id=11951&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #12581 Updated: boolean fields not imported (patchesenclosed)

[Jani Taskinen]

On Mon, 6 Aug 2001, Andy wrote:

>I didn't think that opening a bug report just to
>put a patch in it was correct.  Patches are
>supposed to be sent to the php-dev mailing list.
>Was I wrong?

Yes and no. There are no (that I know of) guidelines
for this. But if a bug report with a patch to a bug
is as valid as a report without a patch, it's even more valuable.
'Duplicate' would be more correct status. In this case,
make the report without a patch the duplicate one.

Ideal solution (IMO) is to have the patch sender to submit a bug report
but have them put the patches somewhere where they can be downloaded.
This way the patch files won't get garbled.

--Jani


>On Sun, 05 Aug 2001, Jani Taskinen wrote:
>> Could you please tell me what is the 'Bogus' in this report?
>> It's a bug report which happens to have a patch for the bug too.
>> This is far from bogus report. Reopened.
>>
>> --Jani
>>
>>
>> On 5 Aug 2001 [EMAIL PROTECTED] wrote:
>>
>> >ID: 12581
>> >Updated by: andy
>> >Reported By: [EMAIL PROTECTED]
>> >Old Status: Open
>> >Status: Bogus
>> >Bug Type: dBase related
>> >Operating System: Linux 2.2.16-3
>> >PHP Version: 4.0.6
>> >New Comment:
>> >
>> >status -> bogus
>> >
>> >Previous Comments:
>> >
>> >
>> >[2001-08-05 16:18:03] [EMAIL PROTECTED]
>> >
>> >this is not a bug...already forwarded to [EMAIL PROTECTED]
>> >
>> >Thanks for your help, but next time just send it to [EMAIL PROTECTED]
>> >and don't open a bug about it.
>> >
>> >
>> >
>> >[2001-08-05 16:17:47] [EMAIL PROTECTED]
>> >
>> >The file name to which the patches apply is ext/dbase/dbase.c.
>> >
>> >
>> >
>> >[2001-08-05 16:16:32] [EMAIL PROTECTED]
>> >
>> >Below are patches that fix the problem reported 10/20/2000 in bug report #7374.  
>The problem is that when boolean (TRUE or FALSE) fields are present in an imported 
>Dbase file, the value is always imported as FALSE (0).  This problem has been present 
>since 4.0.3.  The patches below were generated using distribution 4.0.6.
>> >
>> >466,467c466
>> >< case 'N':   /* FALLS THROUGH */
>> >< case 'L':   /* FALLS THROUGH */
>> >---
>> >> case 'N':
>> >473a473,486
>> >> case 'L':   /* we used to FALLS THROUGH, but now we check for T/Y and F/N
>> >>and insert 1 or 0, respectively.  db_fdc is the number of
>> >>decimals, which we don't care about.  3/14/01 LEW */
>> >>   if ( (*str_value == 'T') || ( *str_value == 'Y' ) ){
>> >>   add_next_index_long(return_value, strtol("1", NULL, 10));
>> >>   } else {
>> >> if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
>> >>   add_next_index_long(return_value, strtol("0", NULL, 10));
>> >> }
>> >> else {
>> >>   add_next_index_long(return_value, strtol(" ", NULL, 10));
>> >>  }
>> >>   }
>> >>   break;
>> >544,545c557
>> ><   case 'N':   /* FALLS THROUGH */
>> ><   case 'L':   /* FALLS THROUGH */
>> >---
>> >>   case 'N':
>> >551a564,578
>> >>   case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
>> >>and insert 1 or 0, respectively.  db_fdc is the number of
>> >>decimals, which we don't care about.  3/14/01 LEW */
>> >> if ( (*str_value == 'T') || ( *str_value == 'Y') ){
>> >> add_assoc_long(return_value, cur_f->db_fname, strtol("1", 
>NULL, 10));
>> >> } else {
>> >>   if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
>> >>   add_assoc_long(return_value, cur_f->db_fname,strtol("0", 
>NULL, 10));
>> >>}
>> >> else {
>> >>   add_assoc_long(return_value, cur_f->db_fname,strtol(" ", 
>NULL, 10));
>> >>  }
>> >> }
>> >> break;
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>> >Edit this bug report at http://bugs.php.net/?id=12581&edit=1
>> >
>> >
>> >
>
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12596: Definition of array using constants in array doesn't work

[jack]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.5
PHP Bug Type: Class/Object related
Bug description:  Definition of array using constants in array doesn't work

The following piece of code doesn't work:

 10);
}

$b = new B();
var_dump($b);
?>

It produces:

object(b)(1) {
  ["a"]=>
  array(1) {
["A"]=>
int(10)
  }
}

which is unexpected (at least for me).
-- 
Edit bug report at: http://bugs.php.net/?id=12596&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12597: AC_CHECK_LIB on -curl fails if cURL is elsewhere than /usr or /usr/local

[heko]

From: [EMAIL PROTECTED]
Operating system: OpenBSD 2.9-current
PHP version:  4.0CVS-2001-08-06
PHP Bug Type: *Configuration Issues
Bug description:  AC_CHECK_LIB on -curl fails if cURL is elsewhere than /usr or 
/usr/local


AC_CHECK_LIB in ext/curl/config.m4 fails if cURL is
installed elsewhere than /usr/local or /usr, regardless
of --with-curl=[directory] setting. The CHECK_LIB macro
provides an optional fourth argument which should in this
case be set to $CURL_LIBS to make sure the test linking
goes ok.

Patch at:

http://saitti.net/~heko/php/patches/patch-ext_curl_config_m4

Or, inline (let's hope it wraps ok):

Index: ext/curl/config.m4
===
RCS file: /repository/php4/ext/curl/config.m4,v
retrieving revision 1.7
diff -I'$Id' -u -b -B -p -r1.7 config.m4
--- ext/curl/config.m4  27 May 2001 18:52:33 -  1.7
+++ ext/curl/config.m4  6 Aug 2001 13:38:38 -
@@ -48,7 +48,7 @@ if test "$PHP_CURL" != "no"; then
 AC_DEFINE(HAVE_CURL,1,[ ])
   ],[
 AC_MSG_ERROR(There is something wrong. Please check config.log for
more information.)
-  ])
+  ], $CURL_LIBS)
 
   PHP_EXTENSION(curl, $ext_shared)
   PHP_SUBST(CURL_SHARED_LIBADD)

-- 
<-->
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/

-- 
Edit bug report at: http://bugs.php.net/?id=12597&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> thies Mon Aug  6 09:36:09 2001 EDT
> 
>   Modified files:  
> /php4/ext/standardbasic_functions.c incomplete_class.c 
>   php_incomplete_class.h var.c 
> /php4/ext/wddxwddx.c 
>   Log:
>   we can no longer register internal-classes once the script is started. 
>   therefore the "incomplete class" is now registered at MINIT time.

How it's not possible all of a sudden?

-Andrei

"I think it would be a good idea." -- Mahatma Gandhi,
when asked what he thought of Western civilization...

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Fwd: Re: [thies@thieso.net: Re: [PHP-DEV] incomplete class broken?]

[Zeev Suraski]

>Date: Mon, 06 Aug 2001 16:07:55 +0300
>To: "Thies C. Arntzen" <[EMAIL PROTECTED]>
>From: Zeev Suraski <[EMAIL PROTECTED]>
>Subject: Re: [[EMAIL PROTECTED]: Re: [PHP-DEV] incomplete class broken?]
>Cc: "Thies C. Arntzen" <[EMAIL PROTECTED]>, Andi Gutmans <[EMAIL PROTECTED]>
>
>At 16:00 06/08/2001, Thies C. Arntzen wrote:
>> could you elaborate why it doesn't work (anymore)?
>
>Yeah.  We no longer go over the entire class/function tables on shutdown, 
>in order to clean the userland classes/functions.  We traverse the hash's 
>linked list from its end, as userland entries will always be in the 
>end.  When we hit a non userland entry, we stop.  This greatly improves 
>performance.  It does mean, however, that internal entries should no 
>longer be registered during the request.
>
>Zeev

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Thies C. Arntzen]

On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
> On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> > thies   Mon Aug  6 09:36:09 2001 EDT
> > 
> >   Modified files:  
> > /php4/ext/standard  basic_functions.c incomplete_class.c 
> > php_incomplete_class.h var.c 
> > /php4/ext/wddx  wddx.c 
> >   Log:
> >   we can no longer register internal-classes once the script is started. 
> >   therefore the "incomplete class" is now registered at MINIT time.
> 
> How it's not possible all of a sudden?

i don't think this is crucial for the gtk stuff as this
problem only arises once the request ends _and_ a new request
starts. the shutdown in the engine has been changed to only
destruct classes (from the end of the list) until the 1st
internal class is found. so:



would (now) destruct class hallo but not tubu. zeev assured me that
dl()'ing modules that created classes never "really" worked
(it would always have request shutdown-trouble as the
c-module would get unloaded but the class table would still
point into the unloiaded module). i kinda don't like it, but
i take zeevs word that it never worked properly. 

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

By the way, if it's really important, we can look into supporting it.  The 
way it was before - it worked in most cases (assuming you never tried to 
use a class before you dl() the corresponding extension), but could result 
in crashes in other cases.

I don't think it's very important, though.  dl() should most probably be 
deprecated from the language, as it's not supported in thread safe mode, 
it's slow and insecure.  It also creates a host of interesting bugs/buglets 
that are difficult to hunt and fix.  Other than that - it's great :)

Zeev

At 17:22 06/08/2001, Thies C. Arntzen wrote:
>On Mon, Aug 06, 2001 at 09:08:05AM -0500, Andrei Zmievski wrote:
> > On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> > > thies   Mon Aug  6 09:36:09 2001 EDT
> > >
> > >   Modified files:
> > > /php4/ext/standard  basic_functions.c incomplete_class.c
> > > php_incomplete_class.h var.c
> > > /php4/ext/wddx  wddx.c
> > >   Log:
> > >   we can no longer register internal-classes once the script is started.
> > >   therefore the "incomplete class" is now registered at MINIT time.
> >
> > How it's not possible all of a sudden?
>
> i don't think this is crucial for the gtk stuff as this
> problem only arises once the request ends _and_ a new request
> starts. the shutdown in the engine has been changed to only
> destruct classes (from the end of the list) until the 1st
> internal class is found. so:
>
>  class tubu {
> }
> dl("php-gtk");
> class hallo {
> }
> ?>
>
> would (now) destruct class hallo but not tubu. zeev assured me that
> dl()'ing modules that created classes never "really" worked
> (it would always have request shutdown-trouble as the
> c-module would get unloaded but the class table would still
> point into the unloiaded module). i kinda don't like it, but
> i take zeevs word that it never worked properly.
>
> tc

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> i don't think this is crucial for the gtk stuff as this
> problem only arises once the request ends _and_ a new request
> starts. the shutdown in the engine has been changed to only
> destruct classes (from the end of the list) until the 1st
> internal class is found. so:
> 
>  class tubu {
> }
> dl("php-gtk");
> class hallo {
> }
> ?>
> 
> would (now) destruct class hallo but not tubu. zeev assured me that
> dl()'ing modules that created classes never "really" worked
> (it would always have request shutdown-trouble as the
> c-module would get unloaded but the class table would still
> point into the unloiaded module). i kinda don't like it, but
> i take zeevs word that it never worked properly. 

I haven't run into problems with it yet, but I'll keep this in mind, I
guess.

-Andrei
* http://www.zend.com/comm_person.php?id=24 *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> By the way, if it's really important, we can look into supporting it.  The 
> way it was before - it worked in most cases (assuming you never tried to 
> use a class before you dl() the corresponding extension), but could result 
> in crashes in other cases.
> 
> I don't think it's very important, though.  dl() should most probably be 
> deprecated from the language, as it's not supported in thread safe mode, 
> it's slow and insecure.  It also creates a host of interesting bugs/buglets 
> that are difficult to hunt and fix.  Other than that - it's great :)

Deprecate dl()? I think it's one of the most useful functions... :)

-Andrei
* "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> By the way, if it's really important, we can look into supporting it.
> The way it was before - it worked in most cases (assuming you never
> tried to use a class before you dl() the corresponding extension), but
> could result in crashes in other cases.
> 
> I don't think it's very important, though.  dl() should most probably
> be deprecated from the language, as it's not supported in thread safe
> mode, it's slow and insecure.  It also creates a host of interesting
> bugs/buglets that are difficult to hunt and fix.  Other than that -
> it's great :)

Uhm, are you suggesting we take away the possibility of loading
extensions at run-time?

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:42 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > By the way, if it's really important, we can look into supporting it.  The
> > way it was before - it worked in most cases (assuming you never tried to
> > use a class before you dl() the corresponding extension), but could result
> > in crashes in other cases.
> >
> > I don't think it's very important, though.  dl() should most probably be
> > deprecated from the language, as it's not supported in thread safe mode,
> > it's slow and insecure.  It also creates a host of interesting 
> bugs/buglets
> > that are difficult to hunt and fix.  Other than that - it's great :)
>
>Deprecate dl()? I think it's one of the most useful functions... :)

How so?  I can understand that people get used to it, but it's really 
bad.  extensions should be loaded in the php.ini file.  There's really no 
good reason for using dl() over the php.ini method.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:49 06/08/2001, Stig Sæther Bakken wrote:
>[Zeev Suraski <[EMAIL PROTECTED]>]
> > By the way, if it's really important, we can look into supporting it.
> > The way it was before - it worked in most cases (assuming you never
> > tried to use a class before you dl() the corresponding extension), but
> > could result in crashes in other cases.
> >
> > I don't think it's very important, though.  dl() should most probably
> > be deprecated from the language, as it's not supported in thread safe
> > mode, it's slow and insecure.  It also creates a host of interesting
> > bugs/buglets that are difficult to hunt and fix.  Other than that -
> > it's great :)
>
>Uhm, are you suggesting we take away the possibility of loading
>extensions at run-time?

Depending on which run-time you mean, yes.  I don't think it should be 
possible to load extensions from within a PHP script.

Note that dl() never really behaved properly.  It was always broken to one 
degree or another.  Also, it'll be completely unavailable in the thread 
safe version of PHP, so we might as well deprecate it completely.
Loading extensions in the php.ini file is still very much possible.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> How so?  I can understand that people get used to it, but it's really 
> bad.  extensions should be loaded in the php.ini file.  There's really no 
> good reason for using dl() over the php.ini method.

Of course there is. One example is using the same PHP binary to run
scripts that use different extensions that wouldn't necessarily want to
load all the time through php.ini.

-Andrei

When we eliminate the impossible, whatever remains,
however improbable, must be true. -- Sherlock Holmes

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andy]

I disagree, is there any way dl() can be fixed,
because it is a useful function...

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> At 17:49 06/08/2001, Stig Sæther Bakken wrote:
> >[Zeev Suraski <[EMAIL PROTECTED]>]
> > > By the way, if it's really important, we can look into supporting it.
> > > The way it was before - it worked in most cases (assuming you never
> > > tried to use a class before you dl() the corresponding extension), but
> > > could result in crashes in other cases.
> > >
> > > I don't think it's very important, though.  dl() should most probably
> > > be deprecated from the language, as it's not supported in thread safe
> > > mode, it's slow and insecure.  It also creates a host of interesting
> > > bugs/buglets that are difficult to hunt and fix.  Other than that -
> > > it's great :)
> >
> >Uhm, are you suggesting we take away the possibility of loading
> >extensions at run-time?
> 
> Depending on which run-time you mean, yes.  I don't think it should be 
> possible to load extensions from within a PHP script.
> 
> Note that dl() never really behaved properly.  It was always broken to one 
> degree or another.  Also, it'll be completely unavailable in the thread 
> safe version of PHP, so we might as well deprecate it completely.
> Loading extensions in the php.ini file is still very much possible.
> 
> Zeev
> 
> 
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12599: ImageTTFText doesn't open font file

[carlos . a . viana]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.6
PHP Bug Type: GD related
Bug description:  ImageTTFText doesn't open font file

The following code generates this warning (doesn't happen with 4.0.5):
Warning:  Could not find/open font in
d:\public_html\image_create.php on line 357

Code:

-- 
Edit bug report at: http://bugs.php.net/?id=12599&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 17:52 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > How so?  I can understand that people get used to it, but it's really
> > bad.  extensions should be loaded in the php.ini file.  There's really no
> > good reason for using dl() over the php.ini method.
>
>Of course there is. One example is using the same PHP binary to run
>scripts that use different extensions that wouldn't necessarily want to
>load all the time through php.ini.

That's one of the places where the PHP/Web functionality and a 
PHP-standalone functionality collide.  In a Web environment, it really 
makes no sense.

The right solution for that is most probably going to be adding a command 
line option that loads an extension (we already have that for Zend extensions).

Loading extensions from within a script is simply a pain to support, and it 
doesn't really give you anything.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

Please don't just say it's useful, please say why :)
dl() has absolutely nothing over loading in php.ini, and has many drawbacks.

Zeev

At 17:55 06/08/2001, Andy wrote:
>I disagree, is there any way dl() can be fixed,
>because it is a useful function...
>
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > At 17:49 06/08/2001, Stig Sæther Bakken wrote:
> > >[Zeev Suraski <[EMAIL PROTECTED]>]
> > > > By the way, if it's really important, we can look into supporting it.
> > > > The way it was before - it worked in most cases (assuming you never
> > > > tried to use a class before you dl() the corresponding extension), but
> > > > could result in crashes in other cases.
> > > >
> > > > I don't think it's very important, though.  dl() should most probably
> > > > be deprecated from the language, as it's not supported in thread safe
> > > > mode, it's slow and insecure.  It also creates a host of interesting
> > > > bugs/buglets that are difficult to hunt and fix.  Other than that -
> > > > it's great :)
> > >
> > >Uhm, are you suggesting we take away the possibility of loading
> > >extensions at run-time?
> >
> > Depending on which run-time you mean, yes.  I don't think it should be
> > possible to load extensions from within a PHP script.
> >
> > Note that dl() never really behaved properly.  It was always broken to one
> > degree or another.  Also, it'll be completely unavailable in the thread
> > safe version of PHP, so we might as well deprecate it completely.
> > Loading extensions in the php.ini file is still very much possible.
> >
> > Zeev
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

BTW, there's no good reason not to load all of the extensions you may need 
in all of your scripts from php.ini.  Loading many extensions doesn't pose 
a significant/noticeable load.  Loading using dl() does.

Zeev

At 17:52 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > How so?  I can understand that people get used to it, but it's really
> > bad.  extensions should be loaded in the php.ini file.  There's really no
> > good reason for using dl() over the php.ini method.
>
>Of course there is. One example is using the same PHP binary to run
>scripts that use different extensions that wouldn't necessarily want to
>load all the time through php.ini.
>
>-Andrei
>
>When we eliminate the impossible, whatever remains,
>however improbable, must be true. -- Sherlock Holmes

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> BTW, there's no good reason not to load all of the extensions you may need 
> in all of your scripts from php.ini.  Loading many extensions doesn't pose 
> a significant/noticeable load.  Loading using dl() does.

Can you explain why the difference matters?

-Andrei

The church is near but the road is icy;
the bar is far away but I will walk carefully. -- Russian proverb

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> 
> Please don't just say it's useful, please say why :)
> dl() has absolutely nothing over loading in php.ini, and has many drawbacks.
 
Please allow me to coin a new term: "Zeev-ism".  Zeev-isms are of the
form "users don't need X" or "95.6% of the scripts out there don't
need Y". ;-)

The fact is that a lot of people (typically ISP users) don't have
access to php.ini or .htaccess.  If these people need a third party
extension, or one that was not built in their ISP's version of PHP,
they either have to get their ISP to include it (and if the ISP is big
enough and the client small enough, they won't care), or use dl().  If
their ISP hasn't disabled that function, in which case they're screwed
anyway of course.

I do get kinda worried when you pop out a statement like "we're
probably going to deprecate dl() anyway", being able to load
extensions at run-time sort of is one of PEAR's foundations.

Let's try to fix these problems rather than cripping PHP.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix

[Sterling Hughes]

Hey,

The attached patch adds support for passing a variable to
INIT_*CLASS_ENTRY in the name field (instead of just passing a
constant string).  I've needed this for a function which provides
API functionality, registering classes with Zend based on the
information passed to it.

-Sterling

Ps: The Midguard folks needed this feature/ran up against this wall
awhile ago as well.  Its the only reason I was able to find the
problem without hours of painful debugging ;-)


Index: zend_API.h
===
RCS file: /repository/Zend/zend_API.h,v
retrieving revision 1.101
diff -u -r1.101 zend_API.h
--- zend_API.h  2001/08/06 02:48:55 1.101
+++ zend_API.h  2001/08/06 15:06:42
@@ -82,7 +82,7 @@
 #define INIT_CLASS_ENTRY(class_container, class_name, functions)   \
{  
 \
class_container.name = strdup(class_name); 
 \
-   class_container.name_length = sizeof(class_name)-1;
 \
+   class_container.name_length = strlen(class_name);  
+ \
class_container.builtin_functions = functions; 
 \
class_container.handle_function_call = NULL;   
 \
class_container.handle_property_get = NULL;
 \
@@ -92,7 +92,7 @@
 #define INIT_OVERLOADED_CLASS_ENTRY(class_container, class_name, functions, 
handle_fcall, handle_propget, handle_propset) \
{  
 \
class_container.name = strdup(class_name); 
 \
-   class_container.name_length = sizeof(class_name)-1; \
+   class_container.name_length = strlen(class_name);   \
class_container.builtin_functions = functions;  \
class_container.handle_function_call = handle_fcall;\
class_container.handle_property_get = handle_propget;   \


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 18:07 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > BTW, there's no good reason not to load all of the extensions you may need
> > in all of your scripts from php.ini.  Loading many extensions doesn't pose
> > a significant/noticeable load.  Loading using dl() does.
>
>Can you explain why the difference matters?

Sure.  dl() means that module_init is done multiple times.  It also means 
that module_shutdown is done multiple times, *and* has to take care of 
cleaning up after the extension *completely*.  That is, clean whatever 
functions, classes, ini entries and callbacks this function may have 
registered.  Right now, only PHP functions and ini entries (to a degree) 
are handled properly.

Drawbacks:
- It's slow.  We encourage putting expensive operations into the 
module_init, using dl() means they end up being done multiple times.

- Under Apache, it's even worse - since in addition to slowliness, it also 
ends up consuming significantly more memory, since any memory the extension 
allocates in module_init (e.g., the function entries it registers) cannot 
be shared between the processes.

- It prevents the engine from optimizing function calls at compile time, by 
looking at what kind of arguments these functions expect.  This is left for 
run-time, which results in significantly slower run-time performance.

- Literally, none of the extensions properly cleans up after itself, 
leaving PHP in various degrees of instability.  This rarely translates to 
crashes, because people don't usually have a script in which they dl() and 
then use a class, another script in which they use the class without 
dl()'ing first, and call the 2nd script right after calling the 1st 
one.  Still, from a cleanliness perspective and in theory, it's bad.

- Another buglet resulting from this is the crash in debug mode, in case of 
a memory leak inside an extension, which is reported in the bugs db.  It's 
no biggy, but also has no good solution.

I don't think the solution should be fixing all of the extensions to clean 
up after themselves, when the only gain is having dl() work, and when using 
dl() is almost always(*) significantly worse than simply adding the 
extension to the php.ini file.

(*) I can't think of any case in which it isn't, but I'm staying humble :)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

See my letter to Andrei.

I've yet to see an ISP that (knowingly) allows users to load extensions, 
and wouldn't agree to add them to the php.ini file.

This isn't a case of me saying "users don't need X" or "95.6% of the 
scripts out there don't need Y".  This is me saying that dl() is *bad*, 
even if people got used to using it, which is why it should be 
deprecated.  Again, notice that it has been deprecated for a long while in 
thread-safe mode, which means people who develop under Windows (a huge 
share) don't have it for over a year.

dl() is bad in pretty much every sense, including the new sense you 
mentioned in your letter - dl()'ing extensions in a shared 
environment.  Forcing the ISP to admit any extensions into the php.ini file 
before it gets loaded to the server is a good thing.

If dl() is one of PEAR's foundations, it's time to dig it up and replace it 
with something more sound and stable :)  Using php.ini for loading 
extensions should be the way to go.

Zeev

At 18:18 06/08/2001, Stig Sæther Bakken wrote:
>[Zeev Suraski <[EMAIL PROTECTED]>]
> >
> > Please don't just say it's useful, please say why :)
> > dl() has absolutely nothing over loading in php.ini, and has many 
> drawbacks.
>
>Please allow me to coin a new term: "Zeev-ism".  Zeev-isms are of the
>form "users don't need X" or "95.6% of the scripts out there don't
>need Y". ;-)
>
>The fact is that a lot of people (typically ISP users) don't have
>access to php.ini or .htaccess.  If these people need a third party
>extension, or one that was not built in their ISP's version of PHP,
>they either have to get their ISP to include it (and if the ISP is big
>enough and the client small enough, they won't care), or use dl().  If
>their ISP hasn't disabled that function, in which case they're screwed
>anyway of course.
>
>I do get kinda worried when you pop out a statement like "we're
>probably going to deprecate dl() anyway", being able to load
>extensions at run-time sort of is one of PEAR's foundations.
>
>Let's try to fix these problems rather than cripping PHP.
>
>  - Stig
>
>--
>   Stig Sæther Bakken <[EMAIL PROTECTED]>
>   Fast Search & Transfer ASA, Trondheim, Norway

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12600: unexpected behaviour

[tr909]

From: [EMAIL PROTECTED]
Operating system: linux redhat 7.1
PHP version:  4.0.6
PHP Bug Type: Session related
Bug description:  unexpected behaviour

1. when register_globals is off you have to
SET and READ HTTP_SESSION_VARS this is wrong in the docs or 
at least confusing (example 1 on
http://www.php.net/manual/en/ref.session.php )

BUG
2. session_register cannot be called from inside another 
funcion (when trying a by reference call this generates a 
call-time reference error on some servers)

 function & sess_reg($x){
 global $HTTP_SESSION_VARS;
   session_register(& $HTTP_SESSION_VARS[$x]);
   $GLOBALS[$x] = & $HTTP_SESSION_VARS[$x];
 }
 //session_start();
 sess_reg("foo");
 echo $foo++;

when using session_register($HTTP_SESSION_VARS[$x]);
the variable is NOT registered. and when used by reference 
(as in example above) generates a "Warning: Call-time 
pass-by-reference has been deprecated - 
argument passed by value;"

Tr909
-- 
Edit bug report at: http://bugs.php.net/?id=12600&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix

[Zeev Suraski]

It's not a big deal and we can commit it (as it's done in the 
'put-expensive-operations-here' part of PHP, the module-init, hint hint :).

However, is it really necessary?

Zeev

At 05:53 06/08/2001, Sterling Hughes wrote:
> Hey,
>
> The attached patch adds support for passing a variable to
> INIT_*CLASS_ENTRY in the name field (instead of just passing a
> constant string).  I've needed this for a function which provides
> API functionality, registering classes with Zend based on the
> information passed to it.
>
> -Sterling
>
> Ps: The Midguard folks needed this feature/ran up against this wall
> awhile ago as well.  Its the only reason I was able to find the
> problem without hours of painful debugging ;-)
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> Drawbacks:
> - It's slow.  We encourage putting expensive operations into the 
> module_init, using dl() means they end up being done multiple times.
> 
> - Under Apache, it's even worse - since in addition to slowliness, it also 
> ends up consuming significantly more memory, since any memory the extension 
> allocates in module_init (e.g., the function entries it registers) cannot 
> be shared between the processes.

This doesn't apply under the standalone version, which is what I'm
mainly worried about.

> - It prevents the engine from optimizing function calls at compile time, by 
> looking at what kind of arguments these functions expect.  This is left for 
> run-time, which results in significantly slower run-time performance.

Can you quantify "significantly"?

> - Literally, none of the extensions properly cleans up after itself, 
> leaving PHP in various degrees of instability.  This rarely translates to 
> crashes, because people don't usually have a script in which they dl() and 
> then use a class, another script in which they use the class without 
> dl()'ing first, and call the 2nd script right after calling the 1st 
> one.  Still, from a cleanliness perspective and in theory, it's bad.

I see. I wasn't aware that the extension was supposed to clean up the
classes it registers. I will fix PHP-GTK behavior on this.

-Andrei

Linux is like living in a teepee.
No Windows, no Gates, Apache in house.
- Usenet signature

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12597 Updated: AC_CHECK_LIB on -curl fails if cURL is elsewhere than /usr or /usr/local

[sniper]

ID: 12597
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: *Configuration Issues
Operating System: OpenBSD 2.9-current
PHP Version: 4.0CVS-2001-08-06
New Comment:

Fixed in CVS. You also need to have -L$CURL_DIR/lib after
the $CURL_LIBS since the path is not necessarily given
by curl-config.

--Jani


Previous Comments:


[2001-08-06 09:58:09] [EMAIL PROTECTED]


AC_CHECK_LIB in ext/curl/config.m4 fails if cURL is
installed elsewhere than /usr/local or /usr, regardless
of --with-curl=[directory] setting. The CHECK_LIB macro
provides an optional fourth argument which should in this
case be set to $CURL_LIBS to make sure the test linking
goes ok.

Patch at:

http://saitti.net/~heko/php/patches/patch-ext_curl_config_m4

Or, inline (let's hope it wraps ok):

Index: ext/curl/config.m4
===
RCS file: /repository/php4/ext/curl/config.m4,v
retrieving revision 1.7
diff -I'$Id' -u -b -B -p -r1.7 config.m4
--- ext/curl/config.m4  27 May 2001 18:52:33 -  1.7
+++ ext/curl/config.m4  6 Aug 2001 13:38:38 -
@@ -48,7 +48,7 @@ if test "$PHP_CURL" != "no"; then
 AC_DEFINE(HAVE_CURL,1,[ ])
   ],[
 AC_MSG_ERROR(There is something wrong. Please check config.log for more 
information.)
-  ])
+  ], $CURL_LIBS)
 
   PHP_EXTENSION(curl, $ext_shared)
   PHP_SUBST(CURL_SHARED_LIBADD)

-- 
<-->
  Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/






Edit this bug report at http://bugs.php.net/?id=12597&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12600 Updated: unexpected behaviour

[tr909]

ID: 12600
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: linux redhat 7.1
PHP Version: 4.0.6
New Comment:

function sess_reg($x){
global $HTTP_SESSION_VARS;
   $a = & $HTTP_SESSION_VARS[$x];
   session_register($a);
   echo $a;
   $GLOBALS[$x] = & $HTTP_SESSION_VARS[$x];
}  

this seems to work but it is still strange that
  session_register("$HTTP_SESSION_VARS[$x]"); 
or even
  session_register("$HTTP_SESSION_VARS["foo");
do not work inside a function.

even more strange
is that HTTP_SESSION_VARS[$x] does not even exist
at the time you set a reference to it? maybe, i'm
curious now, that session_register() doesn't like
arrays but with register_globals = off you just have
the SESSION-VARS array


Previous Comments:


[2001-08-06 11:23:34] [EMAIL PROTECTED]

1. when register_globals is off you have to
SET and READ HTTP_SESSION_VARS this is wrong in the docs or 
at least confusing (example 1 on
http://www.php.net/manual/en/ref.session.php )

BUG
2. session_register cannot be called from inside another 
funcion (when trying a by reference call this generates a 
call-time reference error on some servers)

 function & sess_reg($x){
 global $HTTP_SESSION_VARS;
   session_register(& $HTTP_SESSION_VARS[$x]);
   $GLOBALS[$x] = & $HTTP_SESSION_VARS[$x];
 }
 //session_start();
 sess_reg("foo");
 echo $foo++;

when using session_register($HTTP_SESSION_VARS[$x]);
the variable is NOT registered. and when used by reference 
(as in example above) generates a "Warning: Call-time 
pass-by-reference has been deprecated - 
argument passed by value;"

Tr909





Edit this bug report at http://bugs.php.net/?id=12600&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12599 Updated: ImageTTFText doesn't open font file

[sniper]

ID: 12599
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: GD related
Operating System: Win98
PHP Version: 4.0.6
New Comment:

This has been fixed in CVS already. Next time, use the search before submitting bug 
reports..

--Jani


Previous Comments:


[2001-08-06 10:56:33] [EMAIL PROTECTED]

The following code generates this warning (doesn't happen with 4.0.5):
Warning:  Could not find/open font in d:\public_html\image_create.php on 
line 357

Code:






Edit this bug report at http://bugs.php.net/?id=12599&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12599 Updated: ImageTTFText doesn't open font file

[sniper]

ID: 12599
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: GD related
Operating System: Win98
PHP Version: 4.0.6
New Comment:

This has been fixed in CVS already. Next time, use the search before submitting bug 
reports..

--Jani


Previous Comments:


[2001-08-06 11:41:27] [EMAIL PROTECTED]

This has been fixed in CVS already. Next time, use the search before submitting bug 
reports..

--Jani




[2001-08-06 10:56:33] [EMAIL PROTECTED]

The following code generates this warning (doesn't happen with 4.0.5):
Warning:  Could not find/open font in d:\public_html\image_create.php on 
line 357

Code:






Edit this bug report at http://bugs.php.net/?id=12599&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12601: Error loading oci8.dll, a entry point is missing .

[csalasa]

From: [EMAIL PROTECTED]
Operating system: windows 2000 profesional
PHP version:  4.0.6
PHP Bug Type: OCI8 related
Bug description:  Error loading oci8.dll, a entry point is missing .

Error loading oci8.dll, a entry point is missing ... to procedure
ocilobopen in oci.dll

he a wanrning unable to load dynamic library, but it's there.
-- 
Edit bug report at: http://bugs.php.net/?id=12601&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix

[Sterling Hughes]

On Mon, 6 Aug 2001, Zeev Suraski wrote:

> It's not a big deal and we can commit it (as it's done in the
> 'put-expensive-operations-here' part of PHP, the module-init, hint hint :).
>

;)

> However, is it really necessary?
>


Well, I have the following function (there maybe bugs, I'm still
debugging it:

/* {{{ adt_status_t adt_register_type(const char *type_name, adt_type *p)
   Register a new abstract data type */
ADT_DECLARE(adt_status_t) adt_register_type(adt_type *p)
{
zend_class_entry ce;
TSRMLS_FETCH();

if (zend_hash_update(ADTG(types),
 p->name,
 strlen(p->name) + 1,
 (void *) p,
 sizeof(adt_type),
 NULL) == FAILURE) {
php_error(E_WARNING, "Cannot register type: %s", p->name);
return -1;
}

p->le_id = zend_register_list_destructors_ex(p->le_dtor, NULL, p->le_name, 
global_module_number);

INIT_OVERLOADED_CLASS_ENTRY(ce, p->name, NULL, adt_method_call_handler,
adt_property_get_handler, adt_property_set_handler);
p->ce = zend_register_internal_class_ex(&ce, NULL, NULL TSRMLS_CC);

return 0;
}
/* }}} */

That's used to register the class.  If you can think of another way
to do (*don't* say macro ;-), then I'd be more than willing to hear
it, but otherwise...

-Sterling


> Zeev
>
> At 05:53 06/08/2001, Sterling Hughes wrote:
> > Hey,
> >
> > The attached patch adds support for passing a variable to
> > INIT_*CLASS_ENTRY in the name field (instead of just passing a
> > constant string).  I've needed this for a function which provides
> > API functionality, registering classes with Zend based on the
> > information passed to it.
> >
> > -Sterling
> >
> > Ps: The Midguard folks needed this feature/ran up against this wall
> > awhile ago as well.  Its the only reason I was able to find the
> > problem without hours of painful debugging ;-)
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Thies C. Arntzen]

On Mon, Aug 06, 2001 at 10:34:34AM -0500, Andrei Zmievski wrote:
> On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > Drawbacks:
> > - It's slow.  We encourage putting expensive operations into the 
> > module_init, using dl() means they end up being done multiple times.
> > 
> > - Under Apache, it's even worse - since in addition to slowliness, it also 
> > ends up consuming significantly more memory, since any memory the extension 
> > allocates in module_init (e.g., the function entries it registers) cannot 
> > be shared between the processes.
> 
> This doesn't apply under the standalone version, which is what I'm
> mainly worried about.
> 
> > - It prevents the engine from optimizing function calls at compile time, by 
> > looking at what kind of arguments these functions expect.  This is left for 
> > run-time, which results in significantly slower run-time performance.
> 
> Can you quantify "significantly"?
> 
> > - Literally, none of the extensions properly cleans up after itself, 
> > leaving PHP in various degrees of instability.  This rarely translates to 
> > crashes, because people don't usually have a script in which they dl() and 
> > then use a class, another script in which they use the class without 
> > dl()'ing first, and call the 2nd script right after calling the 1st 
> > one.  Still, from a cleanliness perspective and in theory, it's bad.
> 
> I see. I wasn't aware that the extension was supposed to clean up the
> classes it registers. I will fix PHP-GTK behavior on this.

don't think there's an API for that. we would have to add the
MODULE_NUMBER to the class-entry and then (when unloading the
module) also destroy the classes that that module defined. i
think constants and functions already do this.

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix

[Andrei Zmievski]

On Sun, 05 Aug 2001, Sterling Hughes wrote:
> That's used to register the class.  If you can think of another way
> to do (*don't* say macro ;-), then I'd be more than willing to hear
> it, but otherwise...

You can just initialize the class entry manually.

-Andrei

"Everything is a matter of a little programming" -- Rasmus Lerdorf

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Thies C. Arntzen wrote:
> don't think there's an API for that. we would have to add the
> MODULE_NUMBER to the class-entry and then (when unloading the
> module) also destroy the classes that that module defined. i
> think constants and functions already do this.

Hmm, right, they don't have module_number..

-Andrei
* Why is it always Segmentation's fault? *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Sterling Hughes]

On Mon, 6 Aug 2001, Andrei Zmievski wrote:

> On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > How so?  I can understand that people get used to it, but it's really
> > bad.  extensions should be loaded in the php.ini file.  There's really no
> > good reason for using dl() over the php.ini method.
>
> Of course there is. One example is using the same PHP binary to run
> scripts that use different extensions that wouldn't necessarily want to
> load all the time through php.ini.
>

Also, just to mention, right now it might not be that big a deal to
load them all in php.ini (well something as big PHP-GTK would be,
but...), however, as PHP gets more and more extensions written in C,
there needs to be this functionality.  All other programming
languages that I know of have the functionality as well

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12603: incorrect --enable-native-ttf, correct - --enable-native-tt

[xakep]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: *Configuration Issues
Bug description:  incorrect --enable-native-ttf, correct - --enable-native-tt

in configure mistake in --enable-native-tt (--enable-native-ttf)
-- 
Edit bug report at: http://bugs.php.net/?id=12603&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12603 Updated: incorrect --enable-native-ttf, correct - --enable-native-tt

[andy]

ID: 12603
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: *Configuration Issues
Operating System: 
PHP Version: 4.0.6
New Comment:

This has been fixed in the CVS for a LOOONG
time...

Previous Comments:


[2001-08-06 12:06:42] [EMAIL PROTECTED]

in configure mistake in --enable-native-tt (--enable-native-ttf)





Edit this bug report at http://bugs.php.net/?id=12603&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix

[Sterling Hughes]

On Mon, 6 Aug 2001, Andrei Zmievski wrote:

> On Sun, 05 Aug 2001, Sterling Hughes wrote:
> > That's used to register the class.  If you can think of another way
> > to do (*don't* say macro ;-), then I'd be more than willing to hear
> > it, but otherwise...
>
> You can just initialize the class entry manually.
>

Yeah, but that sorta eliminates the use of the macro in the first
place :)

> -Andrei
>
> "Everything is a matter of a little programming" -- Rasmus Lerdorf
>

Wow, Rasmus gets his first quote in the Zmievski list. ;-)

-Sterling



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 06:30 06/08/2001, Sterling Hughes wrote:
>On Mon, 6 Aug 2001, Andrei Zmievski wrote:
>
> > On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > > How so?  I can understand that people get used to it, but it's really
> > > bad.  extensions should be loaded in the php.ini file.  There's really no
> > > good reason for using dl() over the php.ini method.
> >
> > Of course there is. One example is using the same PHP binary to run
> > scripts that use different extensions that wouldn't necessarily want to
> > load all the time through php.ini.
> >
>
> Also, just to mention, right now it might not be that big a deal to
> load them all in php.ini (well something as big PHP-GTK would be,
> but...), however, as PHP gets more and more extensions written in C,
> there needs to be this functionality.

Why?  Whatever extension you use on your box, put them in the 
php.ini.  dl() is never a better option.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

By the way, I can't really quantify significantly, as it depends on what 
kind of minit you have.  For a module such as the COM module, it can double 
the amount of time it takes the script to run (if you load typelibs).  For 
some other modules, it can be almost anything, if your minit is mostly 
empty.  As a general rule, it's a bad thing, since it repeats things which 
don't have to be repeated.


At 18:34 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > Drawbacks:
> > - It's slow.  We encourage putting expensive operations into the
> > module_init, using dl() means they end up being done multiple times.
> >
> > - Under Apache, it's even worse - since in addition to slowliness, it also
> > ends up consuming significantly more memory, since any memory the 
> extension
> > allocates in module_init (e.g., the function entries it registers) cannot
> > be shared between the processes.
>
>This doesn't apply under the standalone version, which is what I'm
>mainly worried about.
>
> > - It prevents the engine from optimizing function calls at compile 
> time, by
> > looking at what kind of arguments these functions expect.  This is left 
> for
> > run-time, which results in significantly slower run-time performance.
>
>Can you quantify "significantly"?
>
> > - Literally, none of the extensions properly cleans up after itself,
> > leaving PHP in various degrees of instability.  This rarely translates to
> > crashes, because people don't usually have a script in which they dl() and
> > then use a class, another script in which they use the class without
> > dl()'ing first, and call the 2nd script right after calling the 1st
> > one.  Still, from a cleanliness perspective and in theory, it's bad.
>
>I see. I wasn't aware that the extension was supposed to clean up the
>classes it registers. I will fix PHP-GTK behavior on this.
>
>-Andrei
>
>Linux is like living in a teepee.
>No Windows, no Gates, Apache in house.
> - Usenet signature

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> By the way, I can't really quantify significantly, as it depends on what 
> kind of minit you have.  For a module such as the COM module, it can double 
> the amount of time it takes the script to run (if you load typelibs).  For 
> some other modules, it can be almost anything, if your minit is mostly 
> empty.  As a general rule, it's a bad thing, since it repeats things which 
> don't have to be repeated.

I thought you meant "significantly" worse run-time perfomance because
the engine can't optimize for function arguments, not because of what
kind of MINIT an extension has. We're still talking about standalone PHP
binary here.

-Andrei

A room without books is like a body without a soul.
  -- Marcus Tullius Cicero (106-43 B.C.)

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Bug #12599 Updated: ImageTTFText doesn't open font file

[Carlos Viana]

I did search it before, with no results.

> ID: 12599
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Closed
> Bug Type: GD related
> Operating System: Win98
> PHP Version: 4.0.6
> New Comment:
> 
> This has been fixed in CVS already. Next time, use the search before 
submitting bug reports..
> 
> --Jani
> 
> 
> Previous Comments:
> --
--
> 
> [2001-08-06 10:56:33] [EMAIL PROTECTED]
> 
> The following code generates this warning (doesn't happen with 4.0.5):
> Warning:  Could not find/open font in 
d:\public_html\image_create.php on line 357
> 
> Code:
>  Header ("Content-type: image/jpeg");
> $im = imagecreate (400, 30);
> $black = ImageColorAllocate ($im, 0, 0, 0);
> $white = ImageColorAllocate ($im, 255, 255, 255);
> ImageTTFText ($im, 20, 0, 10, 20, 
$white, "D:/public_html/fonts/a.ttf", "Testing... Omega: Ω");
> ImageJpeg ($im);
> ImageDestroy ($im);
> ?>
> 
> --
--
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?
id=12599&edit=2
> 
> 
> 

-
Carlos Viana
[[EMAIL PROTECTED]]
[[EMAIL PROTECTED]]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] First snapshot of the Universe PHP extension (PHP-MICO binding)

[David Eriksson]

Hi!

I'm proud to present the first snapshot of the Universe PHP extension.

What is it? It is a CORBA connection using MICO as ORB. It is intended to 
replace the exisiting PHP extension Satellite.

You can access remote or local CORBA objects, and you can create CORBA 
objects in PHP code!

Information, download and demo at:

  http://universe.2good.nu/

Universe not ready for production environment yet... it leaks memory! :-(

If the PHP Group would like me to submit it to the PHP CVS, I will! :-)

Regards,

-\- David Eriksson -/-

"An expert in a particular computer language is really an expert
in the work-arounds necessary to use this language to perform 
useful work." - Richard B. Johnson

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 19:29 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > By the way, I can't really quantify significantly, as it depends on what
> > kind of minit you have.  For a module such as the COM module, it can 
> double
> > the amount of time it takes the script to run (if you load typelibs).  For
> > some other modules, it can be almost anything, if your minit is mostly
> > empty.  As a general rule, it's a bad thing, since it repeats things which
> > don't have to be repeated.
>
>I thought you meant "significantly" worse run-time perfomance because
>the engine can't optimize for function arguments, not because of what
>kind of MINIT an extension has. We're still talking about standalone PHP
>binary here.

Ah.  Well, YMMV.  If you have repeated calls to functions (not class 
methods, these are not optimized), it can be quite significant - you have 
an extra opcode that includes some stack manipulation, string duplication 
and strtolower of the function name, and slower pass_param opcodes.  I 
never actually benchmarked it, but it can be quite significant.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Sterling Hughes]

On Mon, 6 Aug 2001, Zeev Suraski wrote:

> At 06:30 06/08/2001, Sterling Hughes wrote:
> >On Mon, 6 Aug 2001, Andrei Zmievski wrote:
> >
> > > On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > > > How so?  I can understand that people get used to it, but it's really
> > > > bad.  extensions should be loaded in the php.ini file.  There's really no
> > > > good reason for using dl() over the php.ini method.
> > >
> > > Of course there is. One example is using the same PHP binary to run
> > > scripts that use different extensions that wouldn't necessarily want to
> > > load all the time through php.ini.
> > >
> >
> > Also, just to mention, right now it might not be that big a deal to
> > load them all in php.ini (well something as big PHP-GTK would be,
> > but...), however, as PHP gets more and more extensions written in C,
> > there needs to be this functionality.
>
> Why?  Whatever extension you use on your box, put them in the
> php.ini.  dl() is never a better option.
>

What if you use 50 different shared extensions, for different
scripts on the same box? Should you load them all in each time?
I don't think so...

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 07:10 06/08/2001, Sterling Hughes wrote:
> What if you use 50 different shared extensions, for different
> scripts on the same box? Should you load them all in each time?
> I don't think so...

Other than your phobia, there's no real reason not to do it :)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #12599 Updated: ImageTTFText doesn't open font file

[Andy]

Well, then you didn't search for the right
thing...

On Mon, 06 Aug 2001, Carlos Viana wrote:
> I did search it before, with no results.
> 
> > ID: 12599
> > Updated by: sniper
> > Reported By: [EMAIL PROTECTED]
> > Old Status: Open
> > Status: Closed
> > Bug Type: GD related
> > Operating System: Win98
> > PHP Version: 4.0.6
> > New Comment:
> > 
> > This has been fixed in CVS already. Next time, use the search before 
> submitting bug reports..
> > 
> > --Jani
> > 
> > 
> > Previous Comments:
> > --
> --
> > 
> > [2001-08-06 10:56:33] [EMAIL PROTECTED]
> > 
> > The following code generates this warning (doesn't happen with 4.0.5):
> > Warning:  Could not find/open font in 
> d:\public_html\image_create.php on line 357
> > 
> > Code:
> >  > Header ("Content-type: image/jpeg");
> > $im = imagecreate (400, 30);
> > $black = ImageColorAllocate ($im, 0, 0, 0);
> > $white = ImageColorAllocate ($im, 255, 255, 255);
> > ImageTTFText ($im, 20, 0, 10, 20, 
> $white, "D:/public_html/fonts/a.ttf", "Testing... Omega: Ω");
> > ImageJpeg ($im);
> > ImageDestroy ($im);
> > ?>
> > 
> > --
> --
> > 
> > 
> > 
> > ATTENTION! Do NOT reply to this email!
> > To reply, use the web interface found at http://bugs.php.net/?
> id=12599&edit=2
> > 
> > 
> > 
> 
> -
> Carlos Viana
> [[EMAIL PROTECTED]]
> [[EMAIL PROTECTED]]
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> At 07:10 06/08/2001, Sterling Hughes wrote:
> > What if you use 50 different shared extensions, for different
> > scripts on the same box? Should you load them all in each time?
> > I don't think so...
> 
> Other than your phobia, there's no real reason not to do it :)

No performance hit at all?

-Andrei
* Life may be expensive, but it includes an annual free trip around the sun. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 19:40 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > At 07:10 06/08/2001, Sterling Hughes wrote:
> > > What if you use 50 different shared extensions, for different
> > > scripts on the same box? Should you load them all in each time?
> > > I don't think so...
> >
> > Other than your phobia, there's no real reason not to do it :)
>
>No performance hit at all?

Nothing measurable.  That was actually measured (changing PHP to initialize 
extensions just-in-time, in case they're actually being used) - and it 
turned out it wasn't giving any noticeable performance gain.

If there were a thousand extensions, we may have to rethink it - but the 
good solution would probably be JIT initialization.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Andrei Zmievski]

On Mon, 06 Aug 2001, Zeev Suraski wrote:
> Nothing measurable.  That was actually measured (changing PHP to initialize 
> extensions just-in-time, in case they're actually being used) - and it 
> turned out it wasn't giving any noticeable performance gain.
> 
> If there were a thousand extensions, we may have to rethink it - but the 
> good solution would probably be JIT initialization.

I have no problems with JIT-Init. We even have a marketable name for it,
then. :)

-Andrei
* Marriage is not a word. It's a sentence. Life-long sentence. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 19:45 06/08/2001, Andrei Zmievski wrote:
>On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > Nothing measurable.  That was actually measured (changing PHP to 
> initialize
> > extensions just-in-time, in case they're actually being used) - and it
> > turned out it wasn't giving any noticeable performance gain.
> >
> > If there were a thousand extensions, we may have to rethink it - but the
> > good solution would probably be JIT initialization.
>
>I have no problems with JIT-Init. We even have a marketable name for it,
>then. :)

:)
Anyway, I'm off for a few hours now, reinstalling my machine.  I'll answer 
anything that comes up when I get back ;)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Sterling Hughes]

On Mon, 6 Aug 2001, Zeev Suraski wrote:

> At 19:40 06/08/2001, Andrei Zmievski wrote:
> >On Mon, 06 Aug 2001, Zeev Suraski wrote:
> > > At 07:10 06/08/2001, Sterling Hughes wrote:
> > > > What if you use 50 different shared extensions, for different
> > > > scripts on the same box? Should you load them all in each time?
> > > > I don't think so...
> > >
> > > Other than your phobia, there's no real reason not to do it :)
> >
> >No performance hit at all?
>
> Nothing measurable.  That was actually measured (changing PHP to initialize
> extensions just-in-time, in case they're actually being used) - and it
> turned out it wasn't giving any noticeable performance gain.
>
> If there were a thousand extensions, we may have to rethink it - but the
> good solution would probably be JIT initialization.
>

Interesting -- what about the extra weight of 50 extensions instead
of just one?

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11933 Updated: array_map causes segfault

[andrei]

ID: 11933
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Old Operating System: Debian GNU/Linux "sid" (kernel 2
Operating System: Debian GNU/Linux \"sid\" (kernel 2
PHP Version: 4.0.6
New Comment:

Are you running Zend optimizer by any chance?

Previous Comments:


[2001-07-06 10:25:03] [EMAIL PROTECTED]

I have a script which seems to arbitrarily crash. Removing
all uses of array_map corrects the problem, even though the
apparent point of crash isn't anywhere near a call to
array_map. I'd attach the script but it's rather long and I
don't have time to whittle it down to a minimum case.

gdb backtrace:

#0  0x4024e390 in call_user_function_ex () from
/usr/lib/apache/1.3/libphp4.so
#1  0x402967eb in php_if_array_map () from
/usr/lib/apache/1.3/libphp4.so
#2  0x40247d09 in execute () from /usr/lib/apache/1.3/libphp4.so
#3  0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so
#4  0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so
#5  0x4025654e in zend_execute_scripts () from
/usr/lib/apache/1.3/libphp4.so
#6  0x40268224 in php_execute_script () from
/usr/lib/apache/1.3/libphp4.so
#7  0x4026488f in apache_php_module_main () from
/usr/lib/apache/1.3/libphp4.so
#8  0x4026526e in php_restore_umask () from
/usr/lib/apache/1.3/libphp4.so
#9  0x402652aa in php_restore_umask () from
/usr/lib/apache/1.3/libphp4.so
#10 0x8054204 in ap_invoke_handler ()
#11 0x806306c in ap_some_auth_required ()
#12 0x80630c8 in ap_process_request ()
#13 0x805cc29 in ap_child_terminate ()
#14 0x805cdbc in ap_child_terminate ()
#15 0x805ced9 in ap_child_terminate ()
#16 0x805d395 in ap_child_terminate ()
#17 0x805da5d in main ()
#18 0x400e438b in __libc_start_main () from /lib/libc.so.6





Edit this bug report at http://bugs.php.net/?id=11933&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12477 Updated: preg_replace evaluates dollar signs as variables (eg $1,000 becomes ,000)

[andrei]

ID: 12477
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Linux and SCO
PHP Version: 4.0.6
New Comment:

That's right, you need to escape $ in your replacement strings.

Previous Comments:


[2001-07-31 00:40:54] [EMAIL PROTECTED]

The setup for my templating system:

$template=array(
  "/({PAGETOP})/",
  "/({PAGENAVBAR})/",
  "/({PAGEMAIN})/",
  "/({PAGELINKS})/",
  "/({PAGESPACE})/",
  "/({PAGETEXT})/",
  "/({PAGENEWS})/",
  "/({PAGEBOTTOM})/",
  "/({PAGEDATA})/"
  );

$pagevars=array(
  "PAGETOP" => get_page($site->page_top),
  "PAGENAVBAR" => get_page($site->page_top),
  "PAGEMAIN" => get_page($site->page_main),
  "PAGELINKS" => get_page($site->page_links),,
  "PAGESPACE" => get_page($site->page_space),
  "PAGETEXT" => get_page($site->page_text),
  "PAGENEWS" => get_page($site->page_news),,
  "PAGEBOTTOM" => get_page($site->page_bottom),
  "PAGEDATA" => ""
  );

$page = "{PAGETOP}{PAGENAVBAR}{PAGEMAIN}{PAGEBOTTOM}";

$page = preg_replace($template,$pagevars,$page);

echo $page;

Basically each physical page referenced via the get_page function is a text template 
that may contain HTML, text or variables in the form {VAR}.

Eventually content from a database ends up in a variable called PAGEDATA which is in 
the template stored in the page main variable.

The problem:

PAGEDATA ends up containing page text and it has something like "would cost around 
$16,000 to complete" in that text.

When the preg_replace is performed, something somewhere is assuming that $16 is a 
variable (which doesn't exist) and the text ends up as "would cost around ,000 to 
complete"








Edit this bug report at http://bugs.php.net/?id=12477&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11933 Updated: array_map causes segfault

[andy]

ID: 11933
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Old Operating System: Debian GNU/Linux "sid" (kernel 2
Operating System: Debian GNU/Linux sid (kernel 2
PHP Version: 4.0.6
New Comment:

status -> feedback

Previous Comments:


[2001-08-06 12:47:45] [EMAIL PROTECTED]

Are you running Zend optimizer by any chance?



[2001-07-06 10:25:03] [EMAIL PROTECTED]

I have a script which seems to arbitrarily crash. Removing
all uses of array_map corrects the problem, even though the
apparent point of crash isn't anywhere near a call to
array_map. I'd attach the script but it's rather long and I
don't have time to whittle it down to a minimum case.

gdb backtrace:

#0  0x4024e390 in call_user_function_ex () from
/usr/lib/apache/1.3/libphp4.so
#1  0x402967eb in php_if_array_map () from
/usr/lib/apache/1.3/libphp4.so
#2  0x40247d09 in execute () from /usr/lib/apache/1.3/libphp4.so
#3  0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so
#4  0x40247f5c in execute () from /usr/lib/apache/1.3/libphp4.so
#5  0x4025654e in zend_execute_scripts () from
/usr/lib/apache/1.3/libphp4.so
#6  0x40268224 in php_execute_script () from
/usr/lib/apache/1.3/libphp4.so
#7  0x4026488f in apache_php_module_main () from
/usr/lib/apache/1.3/libphp4.so
#8  0x4026526e in php_restore_umask () from
/usr/lib/apache/1.3/libphp4.so
#9  0x402652aa in php_restore_umask () from
/usr/lib/apache/1.3/libphp4.so
#10 0x8054204 in ap_invoke_handler ()
#11 0x806306c in ap_some_auth_required ()
#12 0x80630c8 in ap_process_request ()
#13 0x805cc29 in ap_child_terminate ()
#14 0x805cdbc in ap_child_terminate ()
#15 0x805ced9 in ap_child_terminate ()
#16 0x805d395 in ap_child_terminate ()
#17 0x805da5d in main ()
#18 0x400e438b in __libc_start_main () from /lib/libc.so.6





Edit this bug report at http://bugs.php.net/?id=11933&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12480 Updated: array_merge_recursive() clobbers existing numeric keys

[andrei]

ID: 12480
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Arrays related
Operating System: FreeBSD
PHP Version: 4.0.6
New Comment:

array_merge* functions are not meant to preserve numeric keys.

Previous Comments:


[2001-07-31 05:14:43] [EMAIL PROTECTED]

if any of the keys of the first level of arrays are
numeric, using array_merge_recursive() will renumber
them to start at 0. this destroys keys that are used
to record id numbers, etc.

[mini:pgl]:~/public_html $ cat test.php 
#!/usr/local/bin/php -q


[mini:pgl]:~/public_html $ ./test.php 
Array
(
[0] => Array
(
[4] => 2
)

[a] => Array
(
[4] => 1
)
)






Edit this bug report at http://bugs.php.net/?id=12480&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12140 Updated: pcre_replace change behavior with \

[andrei]

ID: 12140
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: 
PHP Version: 4.0.6
New Comment:

That's right. Your   turns into  by the time PHP string parsing is done 
with it. Then the extension looks at it and sees two escaped backslashes so that's 
what you get - two backslashes.

In general, use str_replace() for things like that.

Previous Comments:


[2001-07-13 08:51:59] [EMAIL PROTECTED]

task: 
need replace \ (one) to  (four)

On php.4.0.5 work:
$val1=preg_replace('/\\\/',"",$val);

On php 4.0.6 work:
$val1=preg_replace('/\\\/',"",$val);






Edit this bug report at http://bugs.php.net/?id=12140&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12518 Updated: ocifreestatment doesn't free the Oracle cursor and so you run out of cursors

[derek]

ID: 12518
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: OCI8 related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

I have a long-running PHP script that eventually comes up with: 

Failed execution, error: ORA-00604: error occurred at recursive SQL level 2 ORA-01000: 
maximum open cursors exceeded.

I don't explicitly use any cursors in this script btw. In addition I found (via a web 
search) that someone else has been experiencing the same thing.

However, in response to your request I've been trying to build a test script to leak 
cursors and reproduce the problem, unfortunately, thus far, even deliberately leaking 
cursors is not producing it. :(


Previous Comments:


[2001-08-01 16:18:03] [EMAIL PROTECTED]

what makes you belive it doesn't work?

please send me a short testcase that shows leakage of 
resources.






[2001-08-01 13:20:01] [EMAIL PROTECTED]

the ocifreestatment function doesn't actually free the Oracle cursor, these are only 
freed when the script exits.

While this isn't a problem when using PHP as a web page it is a problem if you have a 
command line script that has to perform thousands (or tens of thousands) of queries 
eventually the open_cursors limit is exceeded and all further queries fail.

The same appears to be true with connections.





Edit this bug report at http://bugs.php.net/?id=12518&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11594 Updated: preg_replace is not working with backslash $

[andrei]

ID: 11594
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Solaris
PHP Version: 4.0.5
New Comment:

You need to use '$' as you replacement string.

Previous Comments:


[2001-06-20 17:40:55] [EMAIL PROTECTED]

I'm trying to use preg_replace to replace $ with \$.

Here is a sample script:




I expect the script to output \$_hello_\$world. However, version 4.0.5 is outputing 
$_hello_$world.

This worked in version 4.0.4

It possible this bug is related to bug# 10668







Edit this bug report at http://bugs.php.net/?id=11594&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11236 Updated: addslashes() before preg_replace() gives parse error in regexp

[andrei]

ID: 11236
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.0.5
New Comment:

This works in latest CVS - try upgrading to 4.0.6 or later.

Previous Comments:


[2001-06-11 10:04:46] [EMAIL PROTECTED]

Just an update -- this issue seems to be to do with having lots of single quotes (') 
in the string. It has also been an issue in strings other than the one shown in my 
first post.

6 quotes seems to be the limit of what it can handle.

John



[2001-06-01 07:11:28] [EMAIL PROTECTED]

This issue seems to only affect PHP 4.0.5, not earlier versions, as far as I can tell.

The following code gives an error:



The error is as follows:
[code] EXEC sp_addlinkedserver \'TillDB\', \'Access 2000\', 
\'Microsoft.Jet.OLEDB.4.0\', \'\till01\C\endx\data\ct.mdb\' EXEC sp_addlinkedsrvlogin 
\'TillDB\', false, NULL, \'Admin\', NULL EXEC sp_dropserver \'TIllDB\', \'droplogins\' 
[/code] 
Parse error: parse error in /usr/local/apache/htdocs/test.php(24) : regexp code on 
line 5

Fatal error: Failed evaluating code: stripbrsfromcode(' EXEC sp_addlinkedserver 
\\\'TillDB\\\', \\\'Access 2000\\\', \\\'Microsoft.Jet.OLEDB.4.0\\\', 
\\\'\\till01\\C\\endx\\data\\ct.mdb\\\' EXEC sp_addlinkedsrvlogin \\\'TillDB\\\', 
false, NULL, \\\'Admin\\\', NULL EXEC sp_dropserver \\'TIllDB\\', \\'droplogins\\' ') 
in /usr/local/apache/htdocs/test.php on line 24


Let me know if you need other info. I have seen this problem on two independant 
configurations, so I am fairly sure it is not the server.

phpinfo here:
http://161.58.186.97/phpinfo.php





Edit this bug report at http://bugs.php.net/?id=11236&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10669 Updated: Problem with preg_split

[andrei]

ID: 10669
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PCRE related
Operating System: Linux-2.2.19
PHP Version: 4.0.5
New Comment:

This should work in 4.0.6 and later.

Previous Comments:


[2001-05-04 11:48:56] [EMAIL PROTECTED]

Look at the following code:


In php4.0.4pl1 the result is "5", in php4.0.5 the result is "1".

I also tried version 1.92 in CVS of /ext/pcre/php_pcre.c but I got the same result.

Is this a bug or a change in design ?

Thanks
Renato - Brasil.





Edit this bug report at http://bugs.php.net/?id=10669&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]