#21579 [NEW]: freetype wont compile into php 4.3
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.3.0 PHP Bug Type: GD related Bug description: freetype wont compile into php 4.3 In file included from /usr/src/sources/php/php-4.3.0/ext/gd/libgd/gdft.c:49: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22: ft2build.h: N o such file or directory here is the initial error thens spits out heaps of other gd errors which is too much to paste in, i cannot compile freetype in, but when i take it out php 4.3 compiled fine -- Edit bug report at http://bugs.php.net/?id=21579&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21579&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21579&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21579&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21579&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21579&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21579&r=support Expected behavior: http://bugs.php.net/fix.php?id=21579&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21579&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21579&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21579&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21579&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21579&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21579&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21579&r=gnused
#21579 [Bgs->Opn]: freetype wont compile into php 4.3
ID: 21579 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: GD related Operating System: linux PHP Version: 4.3.0 New Comment: #include #include FT_CONFIG_CONFIG_H #include FT_ERRORS_H #include FT_TYPES_H i had found ft2build.h in /usr/local/etc/freetype/include so i made a symlink to it but even that didnt work ? can i not reply via email what is [EMAIL PROTECTED] ? Previous Comments: [2003-01-11 12:14:31] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [2003-01-11 11:33:03] [EMAIL PROTECTED] Please show the line 41 from your file: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h [2003-01-11 05:33:42] [EMAIL PROTECTED] In file included from /usr/src/sources/php/php-4.3.0/ext/gd/libgd/gdft.c:49: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22: ft2build.h: N o such file or directory here is the initial error thens spits out heaps of other gd errors which is too much to paste in, i cannot compile freetype in, but when i take it out php 4.3 compiled fine -- Edit this bug report at http://bugs.php.net/?id=21579&edit=1
#20263 [Com]: feof doesn't work with --with-curlwrappers
ID: 20263 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Suspended Bug Type: cURL related Operating System: Linux RH 7 PHP Version: 4CVS-2002-11-05 Assigned To: wez New Comment: Don't wait. Act! Since I am the single person who develop libcurl on a regular basis, I can assure you that I don't know what features you're missing and that I am not likely to add them without being pushed in the right direction, most preferably with some hands-on help. Previous Comments: [2002-11-06 03:56:57] [EMAIL PROTECTED] That was the plan. Suspending this for now. Thanks for being eager to try this out; we're really waiting for features in the curl library (otherwise it would be in PHP 4.3). [2002-11-05 10:51:34] [EMAIL PROTECTED] The option is present in 4.3.0pre2 with no mention of the curlwrappers being experimental. If it is known this will not work for 4.3 wouldn't it make sense to remove the configure option from ./configure --help until it works? [2002-11-05 10:29:33] [EMAIL PROTECTED] Wez told me it will be fixed for PHP4.4 and PHP5. They're already working on it so what? Lets keep it open anyway. [2002-11-05 10:25:26] [EMAIL PROTECTED] Nicos is right that it isn't officially supported, but that really doesn't mean you should report bugs about it, on the contrary! [2002-11-05 10:20:53] [EMAIL PROTECTED] Yes, I tested it with and without, once it was disable the script works fine. 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/20263 -- Edit this bug report at http://bugs.php.net/?id=20263&edit=1
#21817 [NEW]: Error to compile php 4.2.3 in make phase
From: [EMAIL PROTECTED] Operating system: Linux Conectiva 8 PHP version: 4.2.3 PHP Bug Type: Compile Failure Bug description: Error to compile php 4.2.3 in make phase I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit bug report at http://bugs.php.net/?id=21817&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21817&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21817&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21817&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21817&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21817&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21817&r=support Expected behavior: http://bugs.php.net/fix.php?id=21817&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21817&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21817&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21817&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21817&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21817&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21817&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21817&r=gnused
#21817 [Fbk->Opn]: Error to compile php 4.2.3 in make phase
ID: 21817 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Linux Conectiva 8 PHP Version: 4.2.3 New Comment: I get the latest version and try to compile and get the following error: gcc -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC -I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php -I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include -I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat -I/usr/src/php/TSRM -g -O2 -c /usr/src/php/ext/imap/php_imap.c -o ext/imap/php_imap.o && echo > ext/imap/php_imap.lo /usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use in this function) /usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is reported only once /usr/src/php/ext/imap/php_imap.c:424: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 Previous Comments: [2003-01-22 08:08:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-22 07:45:52] [EMAIL PROTECTED] I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=21817&edit=1
#21817 [Fbk->Opn]: Error to compile php 4.2.3 in make phase
ID: 21817 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux Conectiva 8 PHP Version: 4.3.1-dev New Comment: Let´s divide your comments: to sniper - -> my configure line is the same I have sended in the first part of my bug report -> In main/php_config, the HAVE_IMAP_AUTH_GSS is defined with 1 value to iliaa - -> I don´t understand what you need (What version of c-client are you using?). Is the version of gcc ? Is the version of anything about imap ? Sorry. Previous Comments: [2003-01-22 19:43:32] [EMAIL PROTECTED] And what configure line did you use? And is HAVE_IMAP_AUTH_GSS defined in main/php_config.h ?? [2003-01-22 15:59:40] [EMAIL PROTECTED] What version of c-client are you using? [2003-01-22 10:28:04] [EMAIL PROTECTED] I get the latest version and try to compile and get the following error: gcc -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC -I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php -I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include -I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat -I/usr/src/php/TSRM -g -O2 -c /usr/src/php/ext/imap/php_imap.c -o ext/imap/php_imap.o && echo > ext/imap/php_imap.lo /usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap': /usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use in this function) /usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is reported only once /usr/src/php/ext/imap/php_imap.c:424: for each function it appears in.) make: *** [ext/imap/php_imap.lo] Error 1 [2003-01-22 08:08:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-22 07:45:52] [EMAIL PROTECTED] I do ./configure with this parameters: '--prefix=/usr/bin' \ '--disable-debug' \ '--enable-pic' \ '--enable-inline-optimization' \ '--enable-shared' \ '--disable-static' \ '--with-config-file-path=/etc/php4/apache' \ '--with-exec-dir=/usr/bin' \ '--with-regex=system' \ '--with-gettext' \ '--with-png' \ '--with-zlib' \ '--enable-magic-quotes' \ '--enable-safe-mode' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--enable-snmp' \ '--enable-ftp' \ '--enable-bcmath' \ '--with-mysql=/usr/src/mysql-3.23.54a' \ '--without-unixODBC' \ '--with-xml' \ '--with-imap' \ '--with-mcrypt=/usr/lib/libmcrypt' \ '--with-readline=/usr/src/readline-4.3' all it´s ok until now, but when I run 'make' this error occurs: root@ php-4.2.3]# make Making all in Zend /bin/sh: cd: Zend: File or directory not found make: *** [all-recursive] Error 1 But Zend directory is there ... Thanks in advance -- Edit this bug report at http://bugs.php.net/?id=21817&edit=1
#21842 [NEW]: sa
From: [EMAIL PROTECTED] Operating system: ssdas PHP version: 4.3.0 PHP Bug Type: mnoGoSearch related Bug description: sa asdsd -- Edit bug report at http://bugs.php.net/?id=21842&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21842&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21842&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21842&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21842&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21842&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21842&r=support Expected behavior: http://bugs.php.net/fix.php?id=21842&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21842&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21842&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21842&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21842&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21842&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21842&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21842&r=gnused
#22213 [Com]: Apache mod_ssl + PHP + cURL SSL segfault
ID: 22213
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: cURL related
Operating System: FreeBSD 4.6-STABLE
PHP Version: 4CVS-2003-02-13 (stable)
New Comment:
How about providing a stack trace or something that shows us what was
going on when it crashed?
For information, libcurl calls only two functions to initialize the
OpenSSL library:
SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)
(The rest is done when some action is called for, and this report says
that isn't required for this problem to occur.)
I honestly can't see how this can be wrong from a libcurl point of
view.
Previous Comments:
[2003-02-14 08:41:39] [EMAIL PROTECTED]
Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.
We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to be a problem
for us.
Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is
present. When apache is run without that flag, it works without any
problems. It crashes only when SSL is running.
("SSLEngine on" only happens with -DSSL)
Thanks.
[2003-02-14 08:33:47] [EMAIL PROTECTED]
The configure command:
./configure --with-apache=/usr/pair/sw/apachessl_1.3.27
--with-config-file-path=/usr/local/etc --enable-magic-quotes
--enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd
--without-ttf --without-msql --with-mysql=/usr/local --with-iodbc
--with-pdflib --enable-inline-optimization --disable-memory-limit
--with-db --without-gdbm --with-ndbm --without-db2 --without-dbm
--with-gettext --without-readline --with-recode
--with-openssl=/usr/local/ssl --with-mcrypt --without-db3 --enable-dba
--with-curl=/usr/local/lib --with-png-dir=/usr/local/lib
Compiling without "--with-curl" fixes the bug. Compiling curl
"--without-ssl" also does the trick.
[2003-02-13 19:22:22] [EMAIL PROTECTED]
And the full configure line used to configure php was..?
[2003-02-13 16:17:05] [EMAIL PROTECTED]
This bug could be related to bug #22112.
[2003-02-13 15:56:40] [EMAIL PROTECTED]
I've reproduced this bug with PHP versions 4.2.2, and the STABLE PHP
dated Feb 13, 2003.
FreeBSD 4.6-stable
PHP 4.2.2 --with-curl
curl --with-ssl, versions 7.9.8 and 7.10.3
Apache 1.3.27 mod_ssl
OpenSSL 0.9.7, and a variety of flavors of 0.9.6.
To reproduce the bug:
* start apache
* send a HUP signal to apache's parent process (to restart it)
The server needn't serve any pages (php or otherwise) before the HUP is
sent. Apache crashes, I believe while trying to reinitialize the
mod_ssl module.
Running the same version of everything, but curl compiled
--without-ssl
makes it work correctly: the apache parent kills off its children and
spawns new ones without the parent segfaulting.
It seems to be dying inside SSL_CTX_ctrl (via SSL_CTX_set_options) when
called from apache's ssl_init_ConfigureServer, at this line:
SSL_CTX_set_options(ctx, SSL_OP_ALL);
Unfortunately, by the time it segfaults, the stack has been corrupted,
and it gets really difficult to debug.
Alan
--
Edit this bug report at http://bugs.php.net/?id=22213&edit=1
#21021 [NEW]: Cant find internal referened functions within a class
From: [EMAIL PROTECTED]
Operating system: Redhat 8
PHP version: 4.3.0RC3
PHP Bug Type: Class/Object related
Bug description: Cant find internal referened functions within a class
Since i have upgraded my entire class script is buggered up.
Call to undefined function: _crypt()
here is the snippets
function login($username,$password,$remember,$page){
$this->db = $GLOBALS['db'];
$this->password = $this->_crypt($password);
$this->_check_username($username);
$this->_check_password($username);
$this->_is_confirmed($username);
if ($this->username_result && $this->pass_result &&
$this->confirmed_result){
$this->_setSession($remember,true);
redirect($page);
//return true;
}
else
// login/pass check failed
{
$this->logout($_SERVER['PHP_SELF'].$this->_build_errorquery($this->result));
}
}
//pass password :: private
function _crypt($password){
return md5($password);
}
i cant honestly see what the reason for this is, i suggest its a bug , as
my script was working before , what is even more wierd , my function was
called _encrypt it wasnt working so i changed it to _crypt and it started
working fine , i have reloaded my page today and its back to the same
error.
--
Edit bug report at http://bugs.php.net/?id=21021&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21021&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21021&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21021&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21021&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21021&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21021&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21021&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21021&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21021&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21021&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21021&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21021&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21021&r=isapi
#21021 [Fbk->Opn]: Cant find internal referened functions within a class
ID: 21021
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: Redhat 8
PHP Version: 4.3.0RC3
New Comment:
class auth {
function login($username,$password){
$this->db = $GLOBALS['db'];
echo $this->password = $this->_crypt($password);
}
//pass password :: private
function _crypt($password){
return md5($password);
}
}
use:
auth::login("dan","bollox");
Previous Comments:
[2002-12-14 18:14:49] [EMAIL PROTECTED]
Please trim down your code to the smallest possible script that shows
the problem AND can be easily copied and pasted for us to test.
Derick
[2002-12-14 18:08:08] [EMAIL PROTECTED]
Since i have upgraded my entire class script is buggered up.
Call to undefined function: _crypt()
here is the snippets
function login($username,$password,$remember,$page){
$this->db = $GLOBALS['db'];
$this->password = $this->_crypt($password);
$this->_check_username($username);
$this->_check_password($username);
$this->_is_confirmed($username);
if ($this->username_result && $this->pass_result &&
$this->confirmed_result){
$this->_setSession($remember,true);
redirect($page);
//return true;
}
else
// login/pass check failed
{
$this->logout($_SERVER['PHP_SELF'].$this->_build_errorquery($this->result));
}
}
//pass password :: private
function _crypt($password){
return md5($password);
}
i cant honestly see what the reason for this is, i suggest its a bug ,
as my script was working before , what is even more wierd , my function
was called _encrypt it wasnt working so i changed it to _crypt and it
started working fine , i have reloaded my page today and its back to
the same error.
--
Edit this bug report at http://bugs.php.net/?id=21021&edit=1
#21021 [Opn]: Cant find internal referened functions within a class
ID: 21021
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Class/Object related
Operating System: Redhat 8
PHP Version: 4.3.0RC3
New Comment:
bugger for some reason the :: reference doesnt work anymore, it was
previously
i tried $auth = new auth();
$auth->login();
and it was ok , i suppose its a me error :)
Previous Comments:
[2002-12-14 18:37:15] [EMAIL PROTECTED]
class auth {
function login($username,$password){
$this->db = $GLOBALS['db'];
echo $this->password = $this->_crypt($password);
}
//pass password :: private
function _crypt($password){
return md5($password);
}
}
use:
auth::login("dan","bollox");
[2002-12-14 18:14:49] [EMAIL PROTECTED]
Please trim down your code to the smallest possible script that shows
the problem AND can be easily copied and pasted for us to test.
Derick
[2002-12-14 18:08:08] [EMAIL PROTECTED]
Since i have upgraded my entire class script is buggered up.
Call to undefined function: _crypt()
here is the snippets
function login($username,$password,$remember,$page){
$this->db = $GLOBALS['db'];
$this->password = $this->_crypt($password);
$this->_check_username($username);
$this->_check_password($username);
$this->_is_confirmed($username);
if ($this->username_result && $this->pass_result &&
$this->confirmed_result){
$this->_setSession($remember,true);
redirect($page);
//return true;
}
else
// login/pass check failed
{
$this->logout($_SERVER['PHP_SELF'].$this->_build_errorquery($this->result));
}
}
//pass password :: private
function _crypt($password){
return md5($password);
}
i cant honestly see what the reason for this is, i suggest its a bug ,
as my script was working before , what is even more wierd , my function
was called _encrypt it wasnt working so i changed it to _crypt and it
started working fine , i have reloaded my page today and its back to
the same error.
--
Edit this bug report at http://bugs.php.net/?id=21021&edit=1
#20987 [Com]: Problem with curl_setopt and client certificates
ID: 20987 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: cURL related Operating System: Redhat Linux 7.2 PHP Version: 4.3.0RC3 New Comment: Basicly, dnorrell wants this little patch applied and I think (s)he is right: diff -u -r1.2 interface.c --- interface.c 14 Nov 2002 11:41:24 - 1.2 +++ interface.c 20 Dec 2002 08:07:16 - @@ -794,6 +794,7 @@ case CURLOPT_USERAGENT: case CURLOPT_FTPPORT: case CURLOPT_COOKIE: + case CURLOPT_SSLCERT: case CURLOPT_COOKIEFILE: case CURLOPT_REFERER: case CURLOPT_INTERFACE: Previous Comments: [2002-12-13 04:48:17] [EMAIL PROTECTED] It appears that if you try to specify a client certficate for an HTTPS connection using the CURLOPT_SSLCERT option, nothing gets set. An example would be: curl_setopt($ch, CURLOPT_SSLCERT, "client.pem"); A quick look at the PHP source seems to indicate that this option is omitted from the curl_setopt function. If I add it it works fine. -- Edit this bug report at http://bugs.php.net/?id=20987&edit=1
Bug #16590: Problems with strings containing \x00
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.2
PHP Bug Type: PCRE related
Bug description: Problems with strings containing \x00
The PCRE has problems with strings containing 0x00. It stops reading as if
the strings were \0 terminated. This affects all preg_* functions.
Examples:
preg_match("/\x00/", "foo");
preg_match("/" . chr(0) . "/", "foo");
Raises the error "Warning: No ending delimiter '/' found"
--
Edit bug report at http://bugs.php.net/?id=16590&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16590&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16590&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16590&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16590&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16590&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16590&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16590&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16590&r=submittedtwice
Bug #16590 Updated: Problems with strings containing \x00
ID: 16590
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.1.2
New Comment:
Actually, I'm not sure whether this problem can be solved as it is PCRE
and not a PHP specific (and it can't be solved without breaking
compatibilty with languages using 0 terminated strings such as C).
I'm thinking about making it a documentation problem. What do you guys
think?
-daniel
Previous Comments:
[2002-04-13 13:06:44] [EMAIL PROTECTED]
The PCRE has problems with strings containing 0x00. It stops reading as
if the strings were \0 terminated. This affects all preg_* functions.
Examples:
preg_match("/\x00/", "foo");
preg_match("/" . chr(0) . "/", "foo");
Raises the error "Warning: No ending delimiter '/' found"
--
Edit this bug report at http://bugs.php.net/?id=16590&edit=1
Bug #16611: Function called from class treats GLOBAL vars in different way...
From: [EMAIL PROTECTED] Operating system: Windows 2000, Windows XP PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Function called from class treats GLOBAL vars in different way... There is the line marked with '//*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit bug report at http://bugs.php.net/?id=16611&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16611&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16611&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16611&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16611&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16611&r=support Expected behavior: http://bugs.php.net/fix.php?id=16611&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16611&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16611&r=submittedtwice
Bug #16609: Function called from class treats GLOBAL vars in different way...
From: [EMAIL PROTECTED] Operating system: Windows 2000, Windows XP PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Function called from class treats GLOBAL vars in different way... There is the line marked with '//*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '//*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit bug report at http://bugs.php.net/?id=16609&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16609&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16609&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16609&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16609&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16609&r=support Expected behavior: http://bugs.php.net/fix.php?id=16609&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16609&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16609&r=submittedtwice
Bug #16610: Function called from class treats GLOBAL vars in different way...
From: [EMAIL PROTECTED] Operating system: Windows 2000, Windows XP PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Function called from class treats GLOBAL vars in different way... There is the line marked with '//*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '//*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit bug report at http://bugs.php.net/?id=16610&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16610&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16610&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16610&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16610&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16610&r=support Expected behavior: http://bugs.php.net/fix.php?id=16610&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16610&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16610&r=submittedtwice
Bug #16612: Function called from class treats GLOBAL vars in different way...
From: [EMAIL PROTECTED] Operating system: Windows 2000, Windows XP PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Function called from class treats GLOBAL vars in different way... There is the line marked with '#*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit bug report at http://bugs.php.net/?id=16612&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16612&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16612&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16612&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16612&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16612&r=support Expected behavior: http://bugs.php.net/fix.php?id=16612&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16612&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16612&r=submittedtwice
Bug #16613: Function called from class treats GLOBAL vars in different way...
From: [EMAIL PROTECTED] Operating system: Windows 2000, Windows XP PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Function called from class treats GLOBAL vars in different way... There is the line marked with '#*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit bug report at http://bugs.php.net/?id=16613&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16613&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16613&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16613&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16613&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16613&r=support Expected behavior: http://bugs.php.net/fix.php?id=16613&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16613&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16613&r=submittedtwice
Bug #16614: Function called from class treats GLOBAL vars in different way...
From: [EMAIL PROTECTED] Operating system: Windows 2000, Windows XP PHP version: 4.1.2 PHP Bug Type: Class/Object related Bug description: Function called from class treats GLOBAL vars in different way... There is the line marked with '#*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit bug report at http://bugs.php.net/?id=16614&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16614&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16614&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16614&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16614&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16614&r=support Expected behavior: http://bugs.php.net/fix.php?id=16614&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16614&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16614&r=submittedtwice
Bug #16609 Updated: Function called from class treats GLOBAL vars in different way...
ID: 16609 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Class/Object related Operating System: Windows 2000, Windows XP PHP Version: 4.1.2 New Comment: Duplicate submission. Sorry. Previous Comments: [2002-04-15 05:37:59] [EMAIL PROTECTED] There is the line marked with '//*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '//*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit this bug report at http://bugs.php.net/?id=16609&edit=1
Bug #16613 Updated: Function called from class treats GLOBAL vars in different way...
ID: 16613 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Class/Object related Operating System: Windows 2000, Windows XP PHP Version: 4.1.2 New Comment: Duplicate submission. Sorry. Previous Comments: [2002-04-15 05:53:37] [EMAIL PROTECTED] There is the line marked with '#*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit this bug report at http://bugs.php.net/?id=16613&edit=1
Bug #16610 Updated: Function called from class treats GLOBAL vars in different way...
ID: 16610 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Class/Object related Operating System: Windows 2000, Windows XP PHP Version: 4.1.2 New Comment: Duplicate submission. Sorry. Previous Comments: [2002-04-15 05:38:21] [EMAIL PROTECTED] There is the line marked with '//*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '//*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit this bug report at http://bugs.php.net/?id=16610&edit=1
Bug #16612 Updated: Function called from class treats GLOBAL vars in different way...
ID: 16612 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Class/Object related Operating System: Windows 2000, Windows XP PHP Version: 4.1.2 New Comment: Duplicate submission. Sorry. Previous Comments: [2002-04-15 05:39:02] [EMAIL PROTECTED] There is the line marked with '#*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit this bug report at http://bugs.php.net/?id=16612&edit=1
Bug #16611 Updated: Function called from class treats GLOBAL vars in different way...
ID: 16611 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Class/Object related Operating System: Windows 2000, Windows XP PHP Version: 4.1.2 New Comment: Duplicate submission. Sorry. Previous Comments: [2002-04-15 05:38:35] [EMAIL PROTECTED] There is the line marked with '//*' in the following script. One line up you will find other line that should make the exactly same action (I think). Try to comment this line and uncomment line with '#*'. The output will differ. Why? --- SCRIPT: START --- --- SCRIPT: END --- -- Edit this bug report at http://bugs.php.net/?id=16611&edit=1
Bug #16681 Updated: Request new words() function returning no of words in string
ID: 16681
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP Home Edition
PHP Version: 4.1.2
New Comment:
I think in PHP it would look like this:
function word_count($string) {
return count(preg_split("/\s+/", $string));
}
Previous Comments:
[2002-04-18 10:15:04] [EMAIL PROTECTED]
I notice that PHP does not have a words() function; I propose that one
is added.
For anybody doing string processing this is an extremely useful
function. It is a commonly found function in other languages (e.g.
REXX). It is not just for general text processing that such a function
is useful, but whenever dealing with strings.
For example, I had a string where I had to take different actions if
there was only 1 word in a string than if there were many.
I agree that you can do this sort of thing with regular expressions,
but hey, you can do a Leveshtein function too with regular expressions
;).
I can guarantee if there was one, it would be widely used.
words(), simply should return the number of words in a string, e.g.
words("hello") -> 1
words("this is my example") -> 4
words(" ah how about this, eh smartass?") -> 6
words("thank you PHP team for taking the time to read this and giving
due consideration for this suggestion rather than just throwing it in
the waste bin because you've got more urgent things to do") -> 35
Hugh Prior
--
Edit this bug report at http://bugs.php.net/?id=16681&edit=1
Bug #16681 Updated: Request new words() function returning no of words in string
ID: 16681
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP Home Edition
PHP Version: 4.1.2
New Comment:
This does not warrant new functions. What you are trying to do should
be done with arrays:
/**/
$countries = array("England", "Spain", "France", "Italy");
print "There are " . count($countries) . " countries competing";
print "The " . count($countries) . " are:";
for ($i=0; $i 1) do_something();
You talk abouts "words" in a string and not "word count" in a string.
Hugh
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/16681
--
Edit this bug report at http://bugs.php.net/?id=16681&edit=1
Bug #16661 Updated: Module crashes if CURL_POSTFIELDS parameter uses in curl_setopt finction
ID: 16661 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: cURL related Operating System: All PHP Version: 4.2.0 New Comment: Don't use curl 7.9.4. Upgrade to 7.9.6. There are several known issues with SSL in 7.9.4. Previous Comments: [2002-04-18 09:41:44] [EMAIL PROTECTED] Are you really using PHP 4.2.0? As that hasn't been released yet. :) Please try the RC (== Release Candidate) from http://www.php.net/~derick/ (I think this was fixed a while ago..) [2002-04-17 10:50:26] [EMAIL PROTECTED] I used file upload through CURL module to other servers and it worked fine still libcurl v. 7.9.4. Of course I could use the older version but in this version don't work connection through SSL and proxy too. I is't powerfull :-(. I got a big problem with file post immediately after upgrade to curl v.7.9.4 Can you resove this problem? I think that CURL is a greatest module by communicative functionality! It is great! And PHP can loose usability if CURL module will work bad. Thank you. Anton Kalmykov [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=16661&edit=1
Bug #16723 Updated: make include_path safe
ID: 16723 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.0 New Comment: then use safe_mode_include_dir instead :) by whatever reason this configuration option can only be found in the CGI version, but not the php version of php.ini. ; When safe_mode is on, UID/GID checks are bypassed when ; including files from this directory and its subdirectories. ; (directory must also be in include_path or full path must ; be used when including) safe_mode_include_dir = Previous Comments: [2002-04-21 13:54:46] [EMAIL PROTECTED] Would it be possible to make include_path 1. Unchangeable (I assume php_admin_value will help here) 2. Safe to include, regardless of uid/gid or open_basedir I host a number of sites on a cluster, and I would like to install some libraries (like phplib) globally, but the current safe_mode prevents that. -- Edit this bug report at http://bugs.php.net/?id=16723&edit=1
Bug #16800 Updated: problem with registration an array variable in session
ID: 16800 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: linux PHP Version: 4.1.2 New Comment: arrays can't be registered in sessions. However, you can store a serialized array: $arr = serialize($array); session_register($arr); -daniel Previous Comments: [2002-04-24 12:46:52] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-04-24 12:28:56] [EMAIL PROTECTED] I've tried to register a seesion variable $array[$i] with sessionn_register(), where $i is an integer index, but failed. In a temporary session file in my /tmp directory I found a declaration like !array[0]|, and now values. Please help! Thanks -- Edit this bug report at http://bugs.php.net/?id=16800&edit=1
Bug #16800 Updated: problem with registration an array variable in session
ID: 16800 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: Session related +Bug Type: Documentation problem Operating System: linux PHP Version: 4.1.2 New Comment: I made it a documentation problem. The manual page for 'session_register()' should explicitly mention this. Previous Comments: [2002-04-24 12:47:56] [EMAIL PROTECTED] arrays can't be registered in sessions. However, you can store a serialized array: $arr = serialize($array); session_register($arr); -daniel [2002-04-24 12:46:52] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-04-24 12:28:56] [EMAIL PROTECTED] I've tried to register a seesion variable $array[$i] with sessionn_register(), where $i is an integer index, but failed. In a temporary session file in my /tmp directory I found a declaration like !array[0]|, and now values. Please help! Thanks -- Edit this bug report at http://bugs.php.net/?id=16800&edit=1
Bug #16800 Updated: problem with registration an array variable in session
ID: 16800
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: linux
PHP Version: 4.1.2
New Comment:
It was not meant to be entertaining. I was serious, but it turned out
to be an user error - sorry for the false alarm.
Here's the typo:
session_register("arr");
instead of
session_register($arr);
damn :)
Previous Comments:
[2002-04-24 14:23:24] [EMAIL PROTECTED]
Just my 2cents: I also hope this is a bad joke. I haven't used sessions
for quite some time but I know definitely that I've fucked the
session_register() function with all kind of variables including arrays
and objects and it worked (without needing to serialize them before
) back when I used them.
[2002-04-24 13:44:20] [EMAIL PROTECTED]
@ [EMAIL PROTECTED]:
I hope that should be a bad joke ...
I've tested the code below with 4.1.1 and it worked.
(session support is broken in 4.1.2 AFAIK)
$bar = array(
'something' => array( 1,2,3,4 ),
'nothing' => NULL,
'test' => true,
'test2' => array( 'x','y'=>2 )
);
session_register('bar');
[2002-04-24 12:49:19] [EMAIL PROTECTED]
I made it a documentation problem. The manual page for
'session_register()' should explicitly mention this.
[2002-04-24 12:47:56] [EMAIL PROTECTED]
arrays can't be registered in sessions. However, you can store a
serialized array:
$arr = serialize($array);
session_register($arr);
-daniel
[2002-04-24 12:46:52] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
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/16800
--
Edit this bug report at http://bugs.php.net/?id=16800&edit=1
Bug #16841: imagepng() segfaults
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.0 PHP Bug Type: Reproducible crash Bug description: imagepng() segfaults generates a reproducable segfault in DSO, CGI and CLI versions. GD is version 1.8.4, although segfaults also occurred with 2.0.1. Libpng is 1.2.1, zlib is 1.1.4. Compiling PHP 4.1.2 identically does not produce the segfault. -- Edit bug report at http://bugs.php.net/?id=16841&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16841&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16841&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16841&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16841&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16841&r=support Expected behavior: http://bugs.php.net/fix.php?id=16841&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16841&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16841&r=submittedtwice
Bug #16841 Updated: imagepng() segfaults
ID: 16841 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux PHP Version: 4.2.0 New Comment: backtrace follows: #0 0xa81 in ?? () #1 0x400d1468 in png_create_write_struct_2 () from /usr/lib/libpng.so.3 #2 0x400d12c9 in png_create_write_struct () from /usr/lib/libpng.so.3 #3 0x8169099 in gdImagePngCtx () #4 0x80ef360 in _php_image_output_ctx (ht=1, return_value=0x8210fe4, this_ptr=0x0, return_value_used=0, image_type=2, tn=0x8187b4b "PNG", func_p=0x8169030 ) at gd_ctx.c:94 #5 0x80f14be in zif_imagepng (ht=1, return_value=0x8210fe4, this_ptr=0x0, return_value_used=0) at gd.c:1479 #6 0x815436a in execute (op_array=0x82111ac) at ./zend_execute.c:1598 #7 0x80cf919 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #8 0x806b3f1 in php_execute_script (primary_file=0xb9c4) at main.c:1381 #9 0x8065821 in main (argc=2, argv=0xba54) at cgi_main.c:785 #10 0x4019774f in __libc_start_main () from /lib/libc.so.6 Previous Comments: [2002-04-25 22:15:41] [EMAIL PROTECTED] To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". [2002-04-25 21:23:20] [EMAIL PROTECTED] generates a reproducable segfault in DSO, CGI and CLI versions. GD is version 1.8.4, although segfaults also occurred with 2.0.1. Libpng is 1.2.1, zlib is 1.1.4. Compiling PHP 4.1.2 identically does not produce the segfault. -- Edit this bug report at http://bugs.php.net/?id=16841&edit=1
Bug #16841 Updated: imagepng() segfaults
ID: 16841 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux PHP Version: 4.2.0 New Comment: I got it to work ok by removing the --with-pdflib from my configure. There's something over at http://www.pdflib.com/pdflib/patches.html which sounds almost relevant (although it affects TIFF routines). I'm running pdflib 4.0.2 Previous Comments: [2002-04-26 02:23:04] [EMAIL PROTECTED] Not closing yet... [2002-04-26 02:21:36] [EMAIL PROTECTED] I think this is the same libgd / libpng 1.2 incompability as we saw before. If you downgrade to libpng 1.0.9 it should work fine. Can you try this? Derick [2002-04-26 01:00:32] [EMAIL PROTECTED] Tested here as well and not able to reproduce. I got a proper PNG. (PHP HEAD and GD-2.0.1) This smells like a local libpng problem to me. The segfault is deep inside libpng. [2002-04-25 23:00:47] [EMAIL PROTECTED] This one looks really strange. It looks like your libpng has some problems. I've the same libs installed and just tested it and it works wihout problems. Can you try cleanly uninstalling it completely from your system and re-installing it [libpng] (best is to try a stable release directly and not the same as you had intalled already on your system). [2002-04-25 22:50:44] [EMAIL PROTECTED] backtrace follows: #0 0xa81 in ?? () #1 0x400d1468 in png_create_write_struct_2 () from /usr/lib/libpng.so.3 #2 0x400d12c9 in png_create_write_struct () from /usr/lib/libpng.so.3 #3 0x8169099 in gdImagePngCtx () #4 0x80ef360 in _php_image_output_ctx (ht=1, return_value=0x8210fe4, this_ptr=0x0, return_value_used=0, image_type=2, tn=0x8187b4b "PNG", func_p=0x8169030 ) at gd_ctx.c:94 #5 0x80f14be in zif_imagepng (ht=1, return_value=0x8210fe4, this_ptr=0x0, return_value_used=0) at gd.c:1479 #6 0x815436a in execute (op_array=0x82111ac) at ./zend_execute.c:1598 #7 0x80cf919 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #8 0x806b3f1 in php_execute_script (primary_file=0xb9c4) at main.c:1381 #9 0x8065821 in main (argc=2, argv=0xba54) at cgi_main.c:785 #10 0x4019774f in __libc_start_main () from /lib/libc.so.6 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/16841 -- Edit this bug report at http://bugs.php.net/?id=16841&edit=1
Bug #16841 Updated: imagepng() segfaults
ID: 16841 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux PHP Version: 4.2.0 New Comment: The simplest configuration I can get it to crash with is: configure --with-zlib --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --pdflib I'm just building the CGI version because it is easier than doing a 'make install' and restarting the Apache etc, but this bug does affect the Apache DSO build as well. The weird thing is that this works fine with PHP 4.1.2, AND the libpng 1.2.1. It seems to look more and more like this bug is pdflib related. Previous Comments: [2002-04-26 09:20:11] [EMAIL PROTECTED] I couldn't reproduce this either with pdflib from pdflib.com. Can you paste the full configure line of PHP and of pdflib ? [2002-04-26 08:34:05] [EMAIL PROTECTED] I got it to work ok by removing the --with-pdflib from my configure. There's something over at http://www.pdflib.com/pdflib/patches.html which sounds almost relevant (although it affects TIFF routines). I'm running pdflib 4.0.2 [2002-04-26 02:23:04] [EMAIL PROTECTED] Not closing yet... [2002-04-26 02:21:36] [EMAIL PROTECTED] I think this is the same libgd / libpng 1.2 incompability as we saw before. If you downgrade to libpng 1.0.9 it should work fine. Can you try this? Derick [2002-04-26 01:00:32] [EMAIL PROTECTED] Tested here as well and not able to reproduce. I got a proper PNG. (PHP HEAD and GD-2.0.1) This smells like a local libpng problem to me. The segfault is deep inside libpng. 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/16841 -- Edit this bug report at http://bugs.php.net/?id=16841&edit=1
Bug #16841 Updated: imagepng() segfaults
ID: 16841 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux PHP Version: 4.2.0 New Comment: Uh, 'configure', 'make', 'make install'. Always worked in the past. Previous Comments: [2002-04-26 21:23:10] [EMAIL PROTECTED] And your pdflib configure line? [2002-04-26 21:18:30] [EMAIL PROTECTED] The simplest configuration I can get it to crash with is: configure --with-zlib --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --pdflib I'm just building the CGI version because it is easier than doing a 'make install' and restarting the Apache etc, but this bug does affect the Apache DSO build as well. The weird thing is that this works fine with PHP 4.1.2, AND the libpng 1.2.1. It seems to look more and more like this bug is pdflib related. [2002-04-26 09:20:11] [EMAIL PROTECTED] I couldn't reproduce this either with pdflib from pdflib.com. Can you paste the full configure line of PHP and of pdflib ? [2002-04-26 08:34:05] [EMAIL PROTECTED] I got it to work ok by removing the --with-pdflib from my configure. There's something over at http://www.pdflib.com/pdflib/patches.html which sounds almost relevant (although it affects TIFF routines). I'm running pdflib 4.0.2 [2002-04-26 02:23:04] [EMAIL PROTECTED] Not closing yet... 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/16841 -- Edit this bug report at http://bugs.php.net/?id=16841&edit=1
Bug #16949 Updated: mysql_query SELECT returns Resource ID
ID: 16949
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *General Issues
Operating System: ?
PHP Version: 4.1.2
New Comment:
I give some help anyway.
Vipervirus, mysql_query returns the connection id. You must use
mysql_fetch_array() to get the values. Please have a look at the
example provided in the manual:
http://www.php.net/manual/en/ref.mysql.php
or
http://www.php.net/manual/en/function.mysql-fetch-array.php
which has some shorter examples. good luck.
Next time please consult the "PHP General" mailinglist:
http://www.php.net/support.php
Previous Comments:
[2002-05-01 16:23:26] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-05-01 16:23:24] [EMAIL PROTECTED]
I've been trying for a week now to fix this, finally gave up on it:
$sql = mysql_query("SELECT pass FROM users WHERE name = '$user'");
echo $sql . "";
when ran, $sql = Resource ID #2 instead of the actual value, I
couldn't
get any help from #php on irc.gamesnet.net
[2002-05-01 16:22:30] [EMAIL PROTECTED]
I've been trying for a week now to fix this, finally gave up on it:
$sql = mysql_query("SELECT pass FROM users WHERE name = '$user'");
echo $sql[pass] . "";
when ran, $sql = Resource ID #2 instead of the actual value, I couldn't
get any help from #php on irc.gamesnet.net
--
Edit this bug report at http://bugs.php.net/?id=16949&edit=1
Bug #16949 Updated: mysql_query SELECT returns Resource ID
ID: 16949
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *General Issues
Operating System: ?
PHP Version: 4.1.2
New Comment:
maybe because it's spelled mysql_QUERY and not mysql_EURY.
I asked you kindly no to use the bug reporting form for support
questions and instead move to the mailing lists. Here's the link
again:
http://www.php.net/support.php
-daniel
Previous Comments:
[2002-05-01 18:48:26] [EMAIL PROTECTED]
I didn't post here intending to ask for help, I was posting a bug
because
$sql = mysql_query("SELECT * FROM users"); works just fine
but $sql = mysql_eury("SELECT * FROM users WHERE name = '$user'");
doesn't work
I've tried this on completely diff servers and got the same result
[2002-05-01 16:37:57] [EMAIL PROTECTED]
I give some help anyway.
Vipervirus, mysql_query returns the connection id. You must use
mysql_fetch_array() to get the values. Please have a look at the
example provided in the manual:
http://www.php.net/manual/en/ref.mysql.php
or
http://www.php.net/manual/en/function.mysql-fetch-array.php
which has some shorter examples. good luck.
Next time please consult the "PHP General" mailinglist:
http://www.php.net/support.php
[2002-05-01 16:23:26] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-05-01 16:23:24] [EMAIL PROTECTED]
I've been trying for a week now to fix this, finally gave up on it:
$sql = mysql_query("SELECT pass FROM users WHERE name = '$user'");
echo $sql . "";
when ran, $sql = Resource ID #2 instead of the actual value, I
couldn't
get any help from #php on irc.gamesnet.net
[2002-05-01 16:22:30] [EMAIL PROTECTED]
I've been trying for a week now to fix this, finally gave up on it:
$sql = mysql_query("SELECT pass FROM users WHERE name = '$user'");
echo $sql[pass] . "";
when ran, $sql = Resource ID #2 instead of the actual value, I couldn't
get any help from #php on irc.gamesnet.net
--
Edit this bug report at http://bugs.php.net/?id=16949&edit=1
Bug #17240 Updated: curl crash with CURLOPT_POSTFIELDS set to ""
ID: 17240 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.19-pre4 (Suse) PHP Version: 4.2.1 New Comment: (I'm the main author of libcurl, in which this crash happens) I believe the problem is related to what data that is actually passed in to libcurl for the CURLOPT_POSTFIELDS option. If CURLOPT_POSTFIELDS is unused, or set to 0 (zero), libcurl will strlen() the previous pointer to find out the length of it. Frame #2 shows the library depending on the pointer and a zero termination. Previous Comments: [2002-05-15 05:49:47] [EMAIL PROTECTED] This script will crash php: http://www.google.com/";); curl_setopt($cs, CURLOPT_RETURNTRANSFER, 1); curl_setopt($cs, CURLOPT_POST, 1); curl_setopt($cs, CURLOPT_POSTFIELDS, ""); echo(curl_exec($cs)); curl_close($cs); ?> $ php -q curltest.php * About to connect() to www.google.com:80 * Connected to www.google.com (216.239.51.101) port 80 Segmentation fault (core dumped) $ gdb /usr/local/bin/php ./core GNU gdb 5.2 ... Loaded symbols for /lib/libnss_dns.so.2 #0 0x40057766 in curl_mvaprintf (format=0x400ca692 "%s", ap_save=0xbfffe1fc) at mprintf.c:1065 1065 info.buffer[info.len] = 0; /* we terminate this with a zero byte */ (gdb) bt #0 0x40057766 in curl_mvaprintf (format=0x400ca692 "%s", ap_save=0xbfffe1fc) at mprintf.c:1065 #1 0x4004ad4a in add_bufferf (in=0x81dd968, fmt=0x400ca692 "%s") at http.c:180 #2 0x4004c33e in Curl_http (conn=0x81dd2c0) at http.c:942 #3 0x40052906 in Curl_do (connp=0xbfffe3e4) at url.c:2428 #4 0x4005b676 in Curl_perform (data=0x81e2928) at transfer.c:1139 #5 0x4005babf in curl_easy_perform (curl=0x81e2928) at easy.c:245 #6 0x080f10a3 in zif_curl_exec (ht=1, return_value=0x81e2024, this_ptr=0x0, return_value_used=1) at curl.c:876 #7 0x0813f6fa in execute (op_array=0x81dd1b4) at ./zend_execute.c:1598 #8 0x080cde49 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #9 0x08066fb1 in php_execute_script (primary_file=0xba44) at main.c:1381 #10 0x080611b1 in main (argc=3, argv=0xbad4) at cgi_main.c:778 #11 0x4018bc6f in __libc_start_main () from /lib/libc.so.6 (gdb) $ php -v 4.2.1 $ curl --version curl 7.9.7 (i686-pc-linux-gnu) libcurl 7.9.7 (OpenSSL 0.9.6c) -- Edit this bug report at http://bugs.php.net/?id=17240&edit=1
Bug #17428 Updated: Fix the tutorial about global variables
ID: 17428
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows XP
PHP Version: 4.2.1
New Comment:
I was a bit surprised as well, as there were no hints on making old
scripts compatible to PHP's new behaviour. In fact, a simple
import_request_variables("gpc"); inserted somewhere at the beginning of
your script (usually every script has a config.php, which is included
by all other files) would be a good workaround until these scripts are
rewritten to "register_globals=off".
Previous Comments:
[2002-05-25 19:12:54] [EMAIL PROTECTED]
The intro tutorial says the following:
One of the most powerful features of PHP is the way it handles HTML
forms. The basic concept that is important to understand is that any
form element in a form will automatically result in a variable with the
same name as the element being created on the target page.
But it is not true any more, since the global variable is turned off by
default since 4.1.2 and it is said that it is bad practice to turn it
on.
There are so many new PHP programmers who stumbled on this one. The
scripts they write according to the tutorial simply do not work.
Also, there are a lot of scripts written before 4.1.2 that use this
feature and they won't work after being downloaded by people who are
not familiar with PHP.
--
Edit this bug report at http://bugs.php.net/?id=17428&edit=1
#19301 [Com]: curl_exec crashes
ID: 19301 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: cURL related Operating System: Windows XP Professional CZ PHP Version: 4.2.3 New Comment: Could this be related to how Windows DLLs vs apps works? In Windows, you can't open a file and pass the handle of that file to have it read from or written to in a DLL. They somehow don't allow that kind of data to be shared like that. It seems as if it could be, the PHP code opens the file and passes the handle to the DLL that deals with it... Just my thoughts. I might be completely wrong. Previous Comments: [2002-09-23 04:52:47] [EMAIL PROTECTED] It seems the bug doesn't affect only WinNT/2K/XP systems but it's also reproductible on Win98SE. [2002-09-12 03:03:37] [EMAIL PROTECTED] Same issue was reported against PHP 4.2.1 in bug 17782. I can see that bug has been thought to be solved as it wasn't reproducible on Linux. Apparenly not the case. It must be a Windows only issue with CURL. The offending code is the functionality enabled with curl_setopt ($ch, CURLOPT_FILE, $fp); with that line enabled curl_exec() crashes (application error/GPF) both when running PHP from commandline and as module under Apache 1.3.26 Disabling above line with CURLOPT_FILE it works, but that is not very usefull in my case as I need CURLOPT_FILE :-) I assume the developer responsible for php_curl.dll (or someone else) will be able to debug this on Windows? >From my point of view this issue is beginning to get a bit critical, so I wouldn't mind to see a quick solution [2002-09-09 07:38:14] [EMAIL PROTECTED] This is propably some win32 issue since I can not reproduce this with PHP 4.2.3 / PHP 4.3.0-dev on Linux. [2002-09-09 07:30:56] [EMAIL PROTECTED] Ooops, I wanted to write 4.2.3, not 4.3.2. Honza [2002-09-09 07:28:51] [EMAIL PROTECTED] Nope, PHP 4.3.2 was the first to get into the system. As I said, I even tested it on clean system (Win2000ProCZ) where nothing else got installed, not even web server (from W2000 i tried it only as php.exe executable), and it gave me the crash on a clean system as well. Honza 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/19301 -- Edit this bug report at http://bugs.php.net/?id=19301&edit=1
#18697 [Com]: HTTPS POST crashing
ID: 18697 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.2.3 New Comment: Being main libcurl author, I'd like to second sniper's request. Please rebuild libcurl with debug symbols and try again. libcurl doesn't use the RAND_add() function itself, why that particular info unfortunately doesn't help in giving any clues here. Previous Comments: [2002-10-14 02:47:15] [EMAIL PROTECTED] Because this PHP/curl is on a production server with 200 websites, it's not that easy to get a chance to re-compile stuff without breaking scripts. I will re-compile curl with debug symbols at some point over the next few days. For your information: a curl HTTPS POST works fine from the command line. [2002-10-12 09:46:43] [EMAIL PROTECTED] Compile curl also with debug symbols enabled.. [2002-10-12 09:46:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. As you can see, the bug is in curl itself. [2002-10-12 03:05:22] [EMAIL PROTECTED] Tried CVS snapshop but got exactly the same crash: (gdb) run -X Starting program: /usr/sbin/httpd -X (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x40512813 in RAND_add () from /usr/local/lib/libcurl.so.2 Cannot access memory at address 0x4000 [2002-10-12 02:21:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip 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/18697 -- Edit this bug report at http://bugs.php.net/?id=18697&edit=1
#20335 [NEW]: Cant override php.ini settings in .htaccess
From: [EMAIL PROTECTED] Operating system: Redhat 7.2 PHP version: 4.3.0-pre2 PHP Bug Type: *Configuration Issues Bug description: Cant override php.ini settings in .htaccess Come across a wierd config bug that happened when i moved from 4.2.2 to 4.3pre2 I have turned register_globals to off in php.ini register_globals = Off I explicitly turn register_globals to on for sites that arent compliant and that will break , have tried different methods like so php_flag register_globals 1 php_value register_globals 1 php_flag register_globals On php_value register_globals On php_flag "register_globals" "1" php_value "register_globals" "1" none of these work used to work by just going php_value register_globals On what could be the problem ? -- Edit bug report at http://bugs.php.net/?id=20335&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20335&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20335&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20335&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20335&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20335&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20335&r=support Expected behavior: http://bugs.php.net/fix.php?id=20335&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20335&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20335&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20335&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20335&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20335&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20335&r=isapi
Bug #12680 Updated: mail() is sent with incorrect timezone
ID: 12680
Updated by: [EMAIL PROTECTED]
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Mail related
Operating System: Windows NT 4.0 SP6
PHP Version: 4.0.6
New Comment:
I found a solution to this problem!
I'm running W2k with IIS5 and PHP 4.1.1.
The mail function has the following parameters,
mail($mail_to, $mail_subject, $mail_body, $mail_headers);
Just add date("r") to the header like:
$mail_headers .= "\nDate: " . date("r");
And the email header will have the correct date!
- daniel
Previous Comments:
[2002-02-08 06:05:17] [EMAIL PROTECTED]
I'm running 4.1.1 on a W2k/IIS5, the bug is not fixed, in which relase
was the bug fix included?
- daniel
[2002-01-30 21:05:50] [EMAIL PROTECTED]
Where can I find out when this bug fix is going to be released? Also
where can I find out which bug fixes where included in previous
release?
TIA
chank
[2001-11-30 04:29:27] [EMAIL PROTECTED]
Fixed in CVS
[2001-08-10 11:01:14] [EMAIL PROTECTED]
This happens with just PHP. As I said, I can directly connect to port
25 and manually enter SMTP commands to send an email (see second mail
header sample). The timezone correctly shows -0500 for CDT. The time
listed in the PHP-created email shows the time correctly, but doesn't
show the timezone correctly (see first mail header sample).
[2001-08-10 10:45:12] [EMAIL PROTECTED]
something similar has been reported as a bug in 4.0 and was
assigned to hholzgra. I don't know if it has been fixed.
Suspended until I can contact him and see if he's fixed it.
If anybody else knows anything about this, second opinion is
welcome.
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/12680
--
Edit this bug report at http://bugs.php.net/?id=12680&edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: read the manual on "variables_order" Previous Comments: [2002-03-13 17:52:15] [EMAIL PROTECTED] It is possible to overwrite some predefined variables using GET URI variables (also, I would imagine, POST vars, but it's harder to test for those). Consider the following as foo.php: \n"; ?> = If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get "blarg" for either of those variables, rather than the value that should have been there from Apache and/or PHP. -- Edit this bug report at http://bugs.php.net/?id=16052&edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: are you sure? HTTP_* variables are environment variables. the variables_order is normally set to EGCPS (if not, change it) where "S" is not "Server Variables" but "SESSION Variables". this behaviour thus looks intentional - first HTTP_ACCEPT_CHARSET is set by the environment, then you overwrite it with a GET. Previous Comments: [2002-03-13 18:56:56] [EMAIL PROTECTED] Incidentally, our variables_order flag is set to "GPCS". [2002-03-13 18:47:07] [EMAIL PROTECTED] Been there, done that. So, why don't any of the other variables from purportedly the same source (s/b "S", yes?) change when I request this on the command line? The point is that either (a) the docs are broken here and the two variables in question aren't from the server, or (b) the EGPCS processing is broken, take your pick. [2002-03-13 18:27:06] [EMAIL PROTECTED] read the manual on "variables_order" [2002-03-13 17:52:15] [EMAIL PROTECTED] It is possible to overwrite some predefined variables using GET URI variables (also, I would imagine, POST vars, but it's harder to test for those). Consider the following as foo.php: \n"; ?> = If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get "blarg" for either of those variables, rather than the value that should have been there from Apache and/or PHP. -- Edit this bug report at http://bugs.php.net/?id=16052&edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: sorry, it's EGPCS by default. Previous Comments: [2002-03-14 02:08:47] [EMAIL PROTECTED] are you sure? HTTP_* variables are environment variables. the variables_order is normally set to EGCPS (if not, change it) where "S" is not "Server Variables" but "SESSION Variables". this behaviour thus looks intentional - first HTTP_ACCEPT_CHARSET is set by the environment, then you overwrite it with a GET. [2002-03-13 18:56:56] [EMAIL PROTECTED] Incidentally, our variables_order flag is set to "GPCS". [2002-03-13 18:47:07] [EMAIL PROTECTED] Been there, done that. So, why don't any of the other variables from purportedly the same source (s/b "S", yes?) change when I request this on the command line? The point is that either (a) the docs are broken here and the two variables in question aren't from the server, or (b) the EGPCS processing is broken, take your pick. [2002-03-13 18:27:06] [EMAIL PROTECTED] read the manual on "variables_order" [2002-03-13 17:52:15] [EMAIL PROTECTED] It is possible to overwrite some predefined variables using GET URI variables (also, I would imagine, POST vars, but it's harder to test for those). Consider the following as foo.php: \n"; ?> = If I now invoke http://www.foo.com/foo.php?HTTP_ACCEPT_CHARSET=blarg or http://www.foo.com/foo.php?HTTP_REFERER=blarg, I get "blarg" for either of those variables, rather than the value that should have been there from Apache and/or PHP. -- Edit this bug report at http://bugs.php.net/?id=16052&edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: No, it was my fault. I thought, session variables were primarily available in $_SESSION, then written to the global context with "variables order". Previous Comments: [2002-03-14 02:41:00] [EMAIL PROTECTED] Funny, the docs say the "S" stands for "Server" variables: http://www.php.net/manual/en/configuration.php#ini.register-globals Furthermore, it doesn't make any comment whatsoever as to the nature of the HTTP_* variables, though the predefined variables page claims some are Apache, and some are environment. http://www.php.net/manual/en/language.variables.predefined.php In this instance, it says HTTP_ACCEPT_CHARSET and HTTP_REFERER are both Apache (presumably, "S"erver, yes?) variables. So are you saying this is a documentation bug? [2002-03-14 02:10:20] [EMAIL PROTECTED] sorry, it's EGPCS by default. [2002-03-14 02:08:47] [EMAIL PROTECTED] are you sure? HTTP_* variables are environment variables. the variables_order is normally set to EGCPS (if not, change it) where "S" is not "Server Variables" but "SESSION Variables". this behaviour thus looks intentional - first HTTP_ACCEPT_CHARSET is set by the environment, then you overwrite it with a GET. [2002-03-13 18:56:56] [EMAIL PROTECTED] Incidentally, our variables_order flag is set to "GPCS". [2002-03-13 18:47:07] [EMAIL PROTECTED] Been there, done that. So, why don't any of the other variables from purportedly the same source (s/b "S", yes?) change when I request this on the command line? The point is that either (a) the docs are broken here and the two variables in question aren't from the server, or (b) the EGPCS processing is broken, take your pick. 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/16052 -- Edit this bug report at http://bugs.php.net/?id=16052&edit=1
Bug #16223 Updated: Nested If block not execute correctly
ID: 16223
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Regular Expressions
Operating System: SUN
PHP Version: 4.1.2
New Comment:
What is $name supposed to be? Your examples (!= or ==) are applying a
completely different logic.
$name = "foo";
If $name is not "test1" => TRUE
This Condition breaks at this point. The second condition is never
executed.
Consider the following Script:
---
\n";
return true;
}
function second() {
echo "second\n";
return true;
}
if(first() || second())
echo "YES\n";
else
echo "NO\n";
?>
---
The output is NOT "first, second, YES" as you might think. It is
"first, YES".
The || operator checks whether either the left condition or the right
condition returns true. If the left condition is true, the right
condition is not anymore checked.
Daniel Lorch
Previous Comments:
[2002-03-22 13:26:06] [EMAIL PROTECTED]
>>If the fruit is not blue or the fruit is not red, do something.
The problem is when the fruit is blue, it still return true, but it has
to return false
[2002-03-22 13:20:45] [EMAIL PROTECTED]
Logic 101
If the fruit is not blue or the fruit is not red, do something.
Since the fruit can only be one colour, that logic will always return
true.
[2002-03-22 13:11:33] [EMAIL PROTECTED]
if ( ( $name != "test1" ) || ( $name != "test2" ) )
does not work properly.
if I Do each condition seperately, it works but If I join them using
|| then this never works
however this works fine
if ( ( $name == "test1" ) || ( $name == "test2" ) )
it seems like the problem occurs only with "!=" condition
--
Edit this bug report at http://bugs.php.net/?id=16223&edit=1
Bug #16287 Updated: SUID for PHP scripts
ID: 16287 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: RH7.2 PHP Version: 4.1.2 New Comment: There is no official solution for this. But you might want to read my posting: http://news.php.net/article.php?group=php.dev&article=81135 although there are some people who believe in the greater security of mod_php as mod_php has no write access to the home directories of the user. feel free to contact me for further questions about php-cgiwrap by private mail. Previous Comments: [2002-03-26 09:52:50] [EMAIL PROTECTED] This is part of Apache &/or the web server responsiblity, doing it in PHP, would (apart from duplicate resources), be a bit security headache.. I believe it is a feature of Apache 2. If you are looking at cgi's, you could consider the php-cgiwrap that is available on the net somewhere. Its not really (AFAIK) ever going to be a php feature. [2002-03-26 09:16:52] [EMAIL PROTECTED] ooops should've changed the status before... [2002-03-26 09:12:48] [EMAIL PROTECTED] Those functions are very good, except they cannot be used in a hosting context where the users are not root... There should be a mechanism like Apache has for .cgi's (per virtual host or location) or dynamically establishing the owner via the home directory lookup. [2002-03-26 09:08:19] [EMAIL PROTECTED] http://php.net/posix_setuid [2002-03-26 09:01:24] [EMAIL PROTECTED] PHP already has functions to swap uids and guids, posix_* (see www.php.net/posix). Derick 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/16287 -- Edit this bug report at http://bugs.php.net/?id=16287&edit=1
Bug #16308 Updated: unregister_globals() - a function that removes all vars by "register_globals"
ID: 16308 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux 2.4 PHP Version: 4.1.2 New Comment: and how do you think unregister_globals() should be able to distinguish between variables set by "register_globals" and those by the user? this will more like lead to a big mess. why not just switch it off? Previous Comments: [2002-03-27 08:31:59] [EMAIL PROTECTED] Hi all! The new globals vars ($_GET, $_POST, etc) are very nice but they do not bring more security if register_globals = on. Regrettably, many server admins are unable to set "register_globals = off" due to the fact that many scripts would broke. I would like to see a 'unregister_globals()'-Function (called at the beginning of a script) which parses the gpc-vars and unsets all normal vars with the same name (let's say it undoes register_globals' work). It would be nice if somebody would inform me if he has such a patch. bye, Roland -- Edit this bug report at http://bugs.php.net/?id=16308&edit=1
Bug #16308 Updated: unregister_globals() - a function that removes all vars by "register_globals"
ID: 16308 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: Linux 2.4 PHP Version: 4.1.2 New Comment: you can set register_globals = off on a vhost base with php_value in your httpd.conf and slowly migrate each user to the new config. Previous Comments: [2002-03-27 08:58:16] [EMAIL PROTECTED] and how do you think unregister_globals() should be able to distinguish between variables set by "register_globals" and those by the user? this will more like lead to a big mess. why not just switch it off? [2002-03-27 08:31:59] [EMAIL PROTECTED] Hi all! The new globals vars ($_GET, $_POST, etc) are very nice but they do not bring more security if register_globals = on. Regrettably, many server admins are unable to set "register_globals = off" due to the fact that many scripts would broke. I would like to see a 'unregister_globals()'-Function (called at the beginning of a script) which parses the gpc-vars and unsets all normal vars with the same name (let's say it undoes register_globals' work). It would be nice if somebody would inform me if he has such a patch. bye, Roland -- Edit this bug report at http://bugs.php.net/?id=16308&edit=1
Bug #16366 Updated: bit shifting error
ID: 16366 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Math related Operating System: WinXP PHP Version: 4.1.2 New Comment: and besides, you should consider using more accurate operators for sensitive data: http://www.php.net/manual/en/ref.bc.php PHP is not actually meant to do real-time calculations or to write 3D-engines in. Also, there is no precalculated sine table and no int 13h in PHP :) 11/34 or bcdiv(11, 34) should do the trick. Previous Comments: [2002-03-31 11:54:25] [EMAIL PROTECTED] AFAIK, PHP stores any number from MySQL as a string, until you access it as a number. If you try to do some math on that number, that will probably not work as expected. Bitshifting won't work either. [2002-03-31 11:48:25] [EMAIL PROTECTED] echo (11>>34) produces "2" Also PHP docs state that the max integer is "usually" 32 bits. So what is an unsigned bigint from mysql stored as, and can I use the bit shift operator on it? -- Edit this bug report at http://bugs.php.net/?id=16366&edit=1
Bug #16366 Updated: bit shifting error
ID: 16366 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Math related Operating System: WinXP PHP Version: 4.1.2 New Comment: why store boolean values in a bigint if someone invented "columns" in SQL? it's a useful thing, you know. but to get your script working, why don't you just binary "&" ? if($data & 2) would check if register two was set. Previous Comments: [2002-03-31 12:27:36] [EMAIL PROTECTED] Hmm well the bug of (11>>34) still exists.. anything >>32 or more should be zero. I'm not really doing math, I am just storing boolean values in all the bits of a bigint, and trying to access the high bits has become a problem. I could always divide by 2 34 times but that kinda sucks. I think I will switch to blobs or something. [2002-03-31 12:21:09] [EMAIL PROTECTED] and besides, you should consider using more accurate operators for sensitive data: http://www.php.net/manual/en/ref.bc.php PHP is not actually meant to do real-time calculations or to write 3D-engines in. Also, there is no precalculated sine table and no int 13h in PHP :) 11/34 or bcdiv(11, 34) should do the trick. [2002-03-31 11:54:25] [EMAIL PROTECTED] AFAIK, PHP stores any number from MySQL as a string, until you access it as a number. If you try to do some math on that number, that will probably not work as expected. Bitshifting won't work either. [2002-03-31 11:48:25] [EMAIL PROTECTED] echo (11>>34) produces "2" Also PHP docs state that the max integer is "usually" 32 bits. So what is an unsigned bigint from mysql stored as, and can I use the bit shift operator on it? -- Edit this bug report at http://bugs.php.net/?id=16366&edit=1
Bug #16366 Updated: bit shifting error
ID: 16366
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Math related
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
> I think I will switch to blobs or something.
the problem is PHP-related. Switching to BLOBs won't solve it.
Why don't you use the ENUM('0','1') data field instead? It is more
humand-friendly (better readable) and somewhat more what the inventor
of databases wanted to do.
You can forget all database-related optimizations because the database
does not understand what you want to do.
Previous Comments:
[2002-03-31 12:43:26] [EMAIL PROTECTED]
why store boolean values in a bigint if someone invented "columns" in
SQL? it's a useful thing, you know.
but to get your script working, why don't you just binary "&" ?
if($data & 2)
would check if register two was set.
[2002-03-31 12:27:36] [EMAIL PROTECTED]
Hmm well the bug of (11>>34) still exists.. anything >>32 or more
should be zero.
I'm not really doing math, I am just storing boolean values in all the
bits of a bigint, and trying to access the high bits has become a
problem. I could always divide by 2 34 times but that kinda sucks.
I think I will switch to blobs or something.
[2002-03-31 12:21:09] [EMAIL PROTECTED]
and besides, you should consider using more accurate operators for
sensitive data:
http://www.php.net/manual/en/ref.bc.php
PHP is not actually meant to do real-time calculations or to write
3D-engines in. Also, there is no precalculated sine table and no int
13h in PHP :)
11/34 or bcdiv(11, 34) should do the trick.
[2002-03-31 11:54:25] [EMAIL PROTECTED]
AFAIK, PHP stores any number from MySQL as a string, until you access
it as a number. If you try to do some math on that number, that will
probably not work as expected. Bitshifting won't work either.
[2002-03-31 11:48:25] [EMAIL PROTECTED]
echo (11>>34) produces "2"
Also PHP docs state that the max integer is "usually" 32 bits. So what
is an unsigned bigint from mysql stored as, and can I use the bit shift
operator on it?
--
Edit this bug report at http://bugs.php.net/?id=16366&edit=1
Bug #16366 Updated: bit shifting error
ID: 16366
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Math related
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
But "32 columns" are the way databases work. You can give names to
these columns and everybody will understand what they are good for.
- If you decide to just have a (int)flags in SQL, how could someone
possibly understand this without reading your documentation (if you
wrote it) or reading through your source code?
- Databases are meant to have columns - commands such as WHERE, ORDER
BY etc.. only work on columns, but not on your homebrewn data format.
- You can add or remove columns, but modifying your flags would end in
a big mess.
- Databases can optimize/cache requests on certain columns (at least I
think they can).
- Using columns is less error-prone.
Why the hell should you STILL be using your custom-made flags-thingie
instead?
But you are right and the bug still exists. PHP has problems with
floating point operations - that's why I suggested to use the "BC"
package.
I wrote a "BC wrapper" which wraps all BC functions to regular PHP
functions. It is meant for people who want to develop their code with
BC, but still want to keep compatibility to PHP installations without
BC. Tell me if you want it.
Previous Comments:
[2002-03-31 12:50:00] [EMAIL PROTECTED]
Daniel: 32 columns or 1 integer, I'd take the integer anytime.
The problem is, that large integers are converted to floats:
>34);
echo ("\nNumber shift 2\n");
echo ($number>>2);
echo("\nBigint shift 29\n");
echo($bigint>>29);
echo("\nBigint shift 30\n");
echo($bigint>>30);
echo("\nBigint shift 31\n");
echo($bigint>>31);
echo("\nBigint shift 32\n");
echo($bigint>>32);
echo("\nBigint shift 33\n");
echo($bigint>>33);
echo("\nBigint shift 1\n");
echo($bigint>>1);
?>
Output:
$ ./test_bit.php
Using values: 11 - 1.1E+32 - 1.1E+33
int(11)
float(1.1E+32)
float(1.1E+33)
Number shift 34
2
Number shift 2
2
Bigint shift 29
0
Bigint shift 30
0
Bigint shift 31
0
Bigint shift 32
0
Bigint shift 33
0
Bigint shift 1
0
[2002-03-31 12:49:34] [EMAIL PROTECTED]
> I think I will switch to blobs or something.
the problem is PHP-related. Switching to BLOBs won't solve it.
Why don't you use the ENUM('0','1') data field instead? It is more
humand-friendly (better readable) and somewhat more what the inventor
of databases wanted to do.
You can forget all database-related optimizations because the database
does not understand what you want to do.
[2002-03-31 12:43:26] [EMAIL PROTECTED]
why store boolean values in a bigint if someone invented "columns" in
SQL? it's a useful thing, you know.
but to get your script working, why don't you just binary "&" ?
if($data & 2)
would check if register two was set.
[2002-03-31 12:27:36] [EMAIL PROTECTED]
Hmm well the bug of (11>>34) still exists.. anything >>32 or more
should be zero.
I'm not really doing math, I am just storing boolean values in all the
bits of a bigint, and trying to access the high bits has become a
problem. I could always divide by 2 34 times but that kinda sucks.
I think I will switch to blobs or something.
[2002-03-31 12:21:09] [EMAIL PROTECTED]
and besides, you should consider using more accurate operators for
sensitive data:
http://www.php.net/manual/en/ref.bc.php
PHP is not actually meant to do real-time calculations or to write
3D-engines in. Also, there is no precalculated sine table and no int
13h in PHP :)
11/34 or bcdiv(11, 34) should do the trick.
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/16366
--
Edit this bug report at http://bugs.php.net/?id=16366&edit=1
Bug #16366 Updated: bit shifting error
ID: 16366
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Math related
Operating System: WinXP
PHP Version: 4.1.2
New Comment:
I'm sorry, but this is not flipcode.com - this is web-development.
Not performance, but maintaineability and readability are crucial.
Always write your code in a way someone else could easily understand
what you are trying to do (even if you'll never release your
sourcecode).
Previous Comments:
[2002-03-31 12:58:54] [EMAIL PROTECTED]
But "32 columns" are the way databases work. You can give names to
these columns and everybody will understand what they are good for.
- If you decide to just have a (int)flags in SQL, how could someone
possibly understand this without reading your documentation (if you
wrote it) or reading through your source code?
- Databases are meant to have columns - commands such as WHERE, ORDER
BY etc.. only work on columns, but not on your homebrewn data format.
- You can add or remove columns, but modifying your flags would end in
a big mess.
- Databases can optimize/cache requests on certain columns (at least I
think they can).
- Using columns is less error-prone.
Why the hell should you STILL be using your custom-made flags-thingie
instead?
But you are right and the bug still exists. PHP has problems with
floating point operations - that's why I suggested to use the "BC"
package.
I wrote a "BC wrapper" which wraps all BC functions to regular PHP
functions. It is meant for people who want to develop their code with
BC, but still want to keep compatibility to PHP installations without
BC. Tell me if you want it.
----
[2002-03-31 12:50:00] [EMAIL PROTECTED]
Daniel: 32 columns or 1 integer, I'd take the integer anytime.
The problem is, that large integers are converted to floats:
>34);
echo ("\nNumber shift 2\n");
echo ($number>>2);
echo("\nBigint shift 29\n");
echo($bigint>>29);
echo("\nBigint shift 30\n");
echo($bigint>>30);
echo("\nBigint shift 31\n");
echo($bigint>>31);
echo("\nBigint shift 32\n");
echo($bigint>>32);
echo("\nBigint shift 33\n");
echo($bigint>>33);
echo("\nBigint shift 1\n");
echo($bigint>>1);
?>
Output:
$ ./test_bit.php
Using values: 11 - 1.1E+32 - 1.1E+33
int(11)
float(1.1E+32)
float(1.1E+33)
Number shift 34
2
Number shift 2
2
Bigint shift 29
0
Bigint shift 30
0
Bigint shift 31
0
Bigint shift 32
0
Bigint shift 33
0
Bigint shift 1
0
[2002-03-31 12:49:34] [EMAIL PROTECTED]
> I think I will switch to blobs or something.
the problem is PHP-related. Switching to BLOBs won't solve it.
Why don't you use the ENUM('0','1') data field instead? It is more
humand-friendly (better readable) and somewhat more what the inventor
of databases wanted to do.
You can forget all database-related optimizations because the database
does not understand what you want to do.
[2002-03-31 12:43:26] [EMAIL PROTECTED]
why store boolean values in a bigint if someone invented "columns" in
SQL? it's a useful thing, you know.
but to get your script working, why don't you just binary "&" ?
if($data & 2)
would check if register two was set.
[2002-03-31 12:27:36] [EMAIL PROTECTED]
Hmm well the bug of (11>>34) still exists.. anything >>32 or more
should be zero.
I'm not really doing math, I am just storing boolean values in all the
bits of a bigint, and trying to access the high bits has become a
problem. I could always divide by 2 34 times but that kinda sucks.
I think I will switch to blobs or something.
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/16366
--
Edit this bug report at http://bugs.php.net/?id=16366&edit=1
Bug #16366 Updated: bit shifting error
ID: 16366 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open -Bug Type: Math related +Bug Type: Documentation problem Operating System: WinXP PHP Version: 4.1.2 New Comment: are you sure? there is already a bunch of reports on "floating-point bugs" in PHP. That's why I didn't reopen it. Previous Comments: [2002-03-31 13:38:51] [EMAIL PROTECTED] Well I have 200 groups of 64 on/off's.. I can name the 200 bigint groups but there is no way in hell I am going to name 12,800 bools, not to mention that they would take up 8x more space in the database.. Each group has the same structure - somebody needs to write a DB that uses structures as custom fields. This may be the way they work but this is ancient design - I was surprised as hell when I started learning MySQL and realized that they are still doing things this way. But anyway. Now I am thinking "char binary" since it can be fixed size, but the documentation on PHP's conversions of MySQL is sparse. If someone would like to pursue this in private email please write. The original bug was about bit shifting, which I don't think would involve a conversion to float.. unless PHP is doing something weird. It looks like someone is just not expecting a shift greater than 32. [2002-03-31 13:27:30] [EMAIL PROTECTED] Good point. Reopening as documentation problem. [2002-03-31 13:23:52] [EMAIL PROTECTED] Related to the bug only: Gives some weird results: $ ./test_float_conversion.php i is 25 int(33554432) int(33554433) int(33554431) i is 26 int(67108864) int(67108865) int(67108863) i is 27 int(134217728) int(134217729) int(134217727) i is 28 int(268435456) int(268435457) int(268435455) i is 29 int(536870912) int(536870913) int(536870911) i is 30 int(1073741824) int(1073741825) int(1073741823) i is 31 float(2147483648) int(-2147483647) float(-2147483649) i is 32 float(4294967296) int(1) int(-1) I guess the manual should be appended, in the 'typecasting' section, to not cast to integer, when it's larger than 2^30 and that those numbers are automatically converted to floats. (http://www.php.net/manual/en/language.types.type-juggling.php#language.types.typecasting) [2002-03-31 13:10:38] [EMAIL PROTECTED] Can you please stop this discussion in the bug system. Fighting about what is best can be done in private mail just fine. Derick [2002-03-31 13:09:00] [EMAIL PROTECTED] I'm sorry, but this is not flipcode.com - this is web-development. Not performance, but maintaineability and readability are crucial. Always write your code in a way someone else could easily understand what you are trying to do (even if you'll never release your sourcecode). 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/16366 -- Edit this bug report at http://bugs.php.net/?id=16366&edit=1
Bug #3708 Updated: Have configure detect missing pieces of modules and generate warnings
ID: 3708 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0 Beta 4 Patch Level 1 New Comment: no, BCMath is not anymore bundled with PHP: Due to changes in the licensing, the BCMATH library is distributed separate from the standard PHP source distribution. You can download the tar-gzipped archive at the url: http://www.php.net/extra/number4.tar.gz. Read the file README.BCMATH in the PHP distribution for more information. http://www.php.net/manual/en/ref.bc.php Previous Comments: [2002-04-01 18:48:38] [EMAIL PROTECTED] Most extensions check that the required libraries are found and if not, the configure breaks at that point and tells what is missing. (and bcmath libraries are bundled with PHP) [2000-03-02 11:52:35] [EMAIL PROTECTED] This was a request to the list. A good idea, if we can ever implement it. Obviously not a big issue, though. " The error message is not particularly meaningful. I suggest that the build process checks for availability of the bcmath stuff and indicates where to download this if the required files are missing. In fact, I suggest that all configure fragments handle this as follows: - if the configuration option requests that a module is included, but the config stuff cannot find that module under the indicated location and any of the default locations, - configure issues a warning including the URL where the missing module can be downloaded. -- [EMAIL PROTECTED]" -- Edit this bug report at http://bugs.php.net/?id=3708&edit=1
Bug #15150 Updated: curl_errno() [still] reports strange numbers
ID: 15150
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: cURL related
Operating System: linux 2.4.16
PHP Version: 4.1.1
New Comment:
I'd suggest a patch similar to this one. This was made against the
current CVS.
diff -u -r1.110 curl.c
--- curl.c 24 Mar 2002 10:40:21 - 1.110
+++ curl.c 3 Apr 2002 13:18:14 -
@@ -797,8 +797,8 @@
}
}
+SAVE_CURL_ERROR(ch, error);
if (error != CURLE_OK) {
- SAVE_CURL_ERROR(ch, error);
RETURN_FALSE;
}
@@ -857,8 +857,8 @@
}
}
+SAVE_CURL_ERROR(ch, error);
if (error != CURLE_OK) {
- SAVE_CURL_ERROR(ch, error);
RETURN_FALSE;
} else {
RETURN_TRUE;
@@ -881,10 +881,10 @@
ZEND_FETCH_RESOURCE(ch, php_curl *, zid, -1, le_curl_name,
le_curl);
error = curl_easy_perform(ch->cp);
+SAVE_CURL_ERROR(ch, error);
if (error != CURLE_OK) {
if (ch->handlers->write->buf.len > 0)
smart_str_free(&ch->handlers->write->buf);
- SAVE_CURL_ERROR(ch, error);
RETURN_FALSE;
}
Previous Comments:
[2002-01-21 10:45:10] [EMAIL PROTECTED]
curl_errno() returns strange wrong values (very large numbers..
negative
numbers etc..)
$ch = curl_init ("http://www.php.net";);
curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_HEADER, 0);
$page=curl_exec ($ch);
$errore=curl_errno($ch);
error_log (" curl_errno: $errore",0);
curl_close ($ch);
my configure options:
'./configure' '--enable-trans-sid' '--with-mm=/usr/local/src/mm-1.1.3'
'--with-mhash'
'--with-apxs=/var/lib/apache/sbin/apxs'
'--with-mysql' '--with-curl'
libcurl version is libcurl 7.9.2
--
Edit this bug report at http://bugs.php.net/?id=15150&edit=1
Bug #16305 Updated: curl post doesn't behave as per the manual
ID: 16305
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
I am Daniel Stenberg, quoted below. That quote is rather old and does
not apply to recent PHP.
What *is* the essence of this report, AFAICT, is somewhat confused (and
the PUT part is entirely incorrect) but I'll try to sum up things:
The bug report should've said:
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded.
I believe this is still true in the most recent versions of
ext/curl/curl.c, but I may be mistaking.
Again, if you pass an array it makes a multipart formpost, if you pass
a string it makes a regular http post.
Previous Comments:
[2002-04-04 07:50:10] [EMAIL PROTECTED]
Reopen if this doesn't work in PHP 4.2.0.
(works fine here)
[2002-04-04 07:44:27] [EMAIL PROTECTED]
Unfortunately, like 90% of people using PHP I am reliant on my host for
compiling and installing PHP, so I can't test it :-(
[2002-04-04 07:34:52] [EMAIL PROTECTED]
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
[2002-03-27 03:49:03] [EMAIL PROTECTED]
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded. This is wrong: the multipart
header should only be used when CURLOPT_PUT is set. To quote the PHP
manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to
do a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message
at <http://curl.haxx.se/mail/curlphp-2001-11/0003.html>:
{{{I took a tour into the inner workings of the php curl wrapper code
and I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this
is that it uses the libcurl function curl_formparse() to accomplish
this, and that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as
the manual testifies.
Regards,
Peter Bowyer.
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1
#17098 [Com]: apache sending 304 - not modified header
ID: 17098 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: linux PHP Version: 4.0CVS-2002-10-17 New Comment: I tried this and tested it with Horde's IMP which heavily needs correct caching behavior. So far it seems to behave very smoothly. I'm impressed of this idea. I took some time but couldn't think of any drawbacks caused by this. Because the unsetting is only internal, there should be no problems with search spiders etc... Any other opinions? Greets, Daniel Previous Comments: [2003-01-03 13:44:12] [EMAIL PROTECTED] As another possible temporary workaround, I tried adding the directive RequestHeader unset If-Modified-Since into my Apache configuration when processing PHP scripts. This removes the If-Modified-Since header entirely, causing Apache to always return a 200 response. The resulting configuration looks like: SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 RequestHeader unset If-Modified-Since Anyone know of a reason why this might be bad or otherwise won't work? Pm [2002-12-29 15:56:05] [EMAIL PROTECTED] Try a NON stable snapshot, it's fixed in CVS> Derick [2002-12-29 15:51:59] [EMAIL PROTECTED] Isn't fixed in php4-STABLE-200212290030 Daniel [datenPUNK] Khan [2002-12-27 14:13:19] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-27 13:55:15] [EMAIL PROTECTED] ... and the bug is present in 4.3.0 release. 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/17098 -- Edit this bug report at http://bugs.php.net/?id=17098&edit=1
#21261 [Com]: $_SERVER['PHP_SELF'] gives wrong info
ID: 21261
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: linux 2.4.18 - slack 8.1
PHP Version: 4.3.0
Assigned To: shane
New Comment:
That (or similar) urgent problem occurs here too. PHP versions before
mid december were not affected IMO.
At first today I've checked out the "php4" and "php5" modules from CVS,
configured, and build them. After installation of the CGI binaries I
detected a problem with $_SERVER['PHP_SELF']:
a) the PHP4 version shows "no value"
b) the PHP5 version shows illegal characters, cut off strings with low
ASCII values etc. Depending on the namebased vhost name the value of
PHP_SELF looks like "ind##" instead of "index.php" ("#" should
represent low ASCII chars, which are shown as boxes here) of just "5"
which is definitely the last char of "index.php5". Short: looks like a
pointer on a string array is bent somewhere.
The problem insist with and without '--enable-force-cgi-redirect' in
both versions. As an example you may want to take a look at
http://daniel-gorski.de/index.php4 (PHP4 CGI)
http://daniel-gorski.de/index.php5 (PHP5 CGI)
and compare the values of $_SERVER['PHP_SELF']. Additionally the PHP5
version has a strange "Zend Extension" date: 90021012. OTOH this value
seems to be correct in the PHP4 version.
The operating system is Linux (RedHat 6.2).
I would appreciate to see this bug solved as soon as possible, because
this is a dramatic show stopper for a few ZE2 applications I am
developing & running.
What required information can I provide to help to solve this problem?
regards dtg
Previous Comments:
[2003-01-09 14:57:05] [EMAIL PROTECTED]
Quick & Dirty PHP-Based workaround:
Put this code in a file and add it to auto_prepend_file-directive in
php.ini:
-snip
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details
$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
strlen($_SERVER['DOCUMENT_ROOT']));
$PHP_SELF =
$SCRIPT_NAME =
$_SERVER['PHP_SELF'] =
$_SERVER['SCRIPT_NAME'];
-snip
Works fine for me... If PHP is used as CLI it may be neccessary to
check current mode before running this code.
[2003-01-07 13:30:23] [EMAIL PROTECTED]
There is no space in SCRIPT_NAME on my localhost, this was an
copy&paste-error. But the "I" at the end exists.
[2003-01-07 13:27:55] [EMAIL PROTECTED]
Same for me, your patch seems to have no affect.
I checked the debugging output from cgiwrap which says:
[...]
Fixing Environment Variables.
Environment Variables:
QUERY_STRING: ''
SCRIPT_NAME: '/phpinfo.php'
SCRIPT_FILENAME: '/phpinfo.php'
REDIRECT_URL: ''
PATH_INFO: '/phpinfo.php'
PATH_TRANSLATED: '/phpinfo.php'
REMOTE_USER: ''
REMOTE_HOST: ''
REMOTE_ADDR: '217.4.137.70'
[...]
Seems to be ok?! But PHP_SELF has no value.
On my localhost PHP 4.3/CGI works with cgiwrap. The same paragraph with
this machine:
[...]
Fixing Environment Variables.
Environment Variables:
QUERY_STRING: ''
SCRIPT_NAME: '/php/ phpinfo.phpI'
SCRIPT_FILENAME: '/php/phpinfo.php'
REDIRECT_URL: ''
PATH_INFO: '/php/phpinfo.php'
PATH_TRANSLATED: '/php/phpinfo.php'
REMOTE_USER: ''
REMOTE_HOST: ''
REMOTE_ADDR: '192.168.23.2'
[...]
In this case, script_name is broken for some reason (don't ask me why,
i didn't find out). But PHP_SELF has the correct value! On both server
SCRIPT_NAME isn't listed in the phpinfo()-Output.
Hope this will help.
[2003-01-07 00:42:23] [EMAIL PROTECTED]
[EMAIL PROTECTED]: email me your httpd.conf, php.ini and the test
script you use. You can remove anything from the files that are
private. Also, as per spec PATH_TRANSLATED will be empty unless you
have PATH_INFO, which is path data *after* the script in a url:
http://host/script.php/path/info?query-string
The only thing I'm concerned about is the garbled PHP_SELF. PHP_SELF
is the same as SCRIPT_NAME, is SCRIPT_N
#21758 [NEW]: PCRE functions were screwed up
From: [EMAIL PROTECTED] Operating system: Linux, Win32 PHP version: 5CVS-2003-01-19 (dev) PHP Bug Type: Scripting Engine problem Bug description: PCRE functions were screwed up Probably this patch screwed up preg_replace_* functions: http://lists.php.net/article.php?group=php.cvs&article=18024 I need the functionality to pass a callback _method_ to preg_replace_callback(). It worked usually like this (in a class): $s = preg_replace_callback(, array(&$this, 'callbackmethod'), $s); Now "array" is forbidden. Is this your intention? How to access callback methods then? regards dtg -- Edit bug report at http://bugs.php.net/?id=21758&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21758&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21758&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21758&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21758&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21758&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21758&r=support Expected behavior: http://bugs.php.net/fix.php?id=21758&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21758&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21758&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21758&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21758&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21758&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21758&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21758&r=gnused
#21758 [Fbk->Opn]: PCRE functions were screwed up
ID: 21758 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: Linux, Win32 PHP Version: 5CVS-2003-01-19 (dev) New Comment: Hi, have already pointed you to the patch that causes this. This has been working before the patch. I've no possibility to test it on Win32 (I've been told by Sebastian Bergmann that it does not work there too). As it has obviously nothing to do with ZE2, both (lastest PHP4-STABLE, and CVS "php5" module) perish on this. Please fix this as soon as possible. "php4-STABLE-200301201030" root@warpcore:/src/php4-STABLE-200301201030/sapi/cli> ./php -v PHP 4.3.1-dev (cli) (built: Jan 20 2003 12:13:11) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies root@warpcore:/src/php4-STABLE-200301201030/sapi/cli> ./php -i | head -13 phpinfo() PHP Version => 4.3.1-dev System => Linux warpcore 2.2.20 #10 Sun Nov 17 22:46:16 CET 2002 i686 Build Date => Jan 20 2003 12:09:35 Configure Command => './configure' '--enable-force-cgi-redirect' '--with-mysql=/usr/local/mysql' '--with-config-file-path=../conf' '--enable-trans-sid' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => ../conf PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 20021010 Debug Build => no root@warpcore:/src/php4-STABLE-200301201030/sapi/cli> cat | ./php Warning: preg_replace_callback() [...]: Parameter mismatch, pattern is a string while replacement in an array. in - on line 11 -- "php5" CVS module: goosh@warpcore:/src/php5/sapi/cli> ./php -v PHP 5.0.0-dev (cli) (built: Jan 20 2003 11:49:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies goosh@warpcore:/src/php5/sapi/cli> ./php -i | head -13 phpinfo() PHP Version => 5.0.0-dev System => Linux warpcore 2.2.20 #10 Sun Nov 17 22:46:16 CET 2002 i686 Build Date => Jan 20 2003 11:46:03 Configure Command => './configure' '--enable-force-cgi-redirect' '--with-mysql=/usr/local/mysql' '--with-config-file-path=../conf' '--enable-trans-sid' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => ../conf PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 90021012 Debug Build => no goosh@warpcore:/src/php5/sapi/cli> cat | ./php Warning: preg_replace_callback() [...]: Parameter mismatch, pattern is a string while replacement in an array. in - on line 7 regards dtg Previous Comments: [2003-01-20 00:29:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip To see if it's ZE2 issue or not..and also, provide a complete, short and self-contained example script so that we can easily reproduce the problem ourselves. [2003-01-19 17:16:03] [EMAIL PROTECTED] Probably this patch screwed up preg_replace_* functions: http://lists.php.net/article.php?group=php.cvs&article=18024 I need the functionality to pass a callback _method_ to preg_replace_callback(). It worked usually like this (in a class): $s = preg_replace_callback(, array(&$this, 'callbackmethod'), $s); Now "array" is forbidden. Is this your intention? How to access callback methods then? regards dtg -- Edit this bug report at http://bugs.php.net/?id=21758&edit=1
#21758 [Csd]: PCRE functions were screwed up
ID: 21758 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: PCRE related Operating System: Linux, Win32 PHP Version: 5CVS-2003-01-19 (dev) New Comment: Thank you for the fast fix. regards dtg Previous Comments: [2003-01-20 10:46:54] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-20 05:23:28] [EMAIL PROTECTED] Hi, have already pointed you to the patch that causes this. This has been working before the patch. I've no possibility to test it on Win32 (I've been told by Sebastian Bergmann that it does not work there too). As it has obviously nothing to do with ZE2, both (lastest PHP4-STABLE, and CVS "php5" module) perish on this. Please fix this as soon as possible. "php4-STABLE-200301201030" root@warpcore:/src/php4-STABLE-200301201030/sapi/cli> ./php -v PHP 4.3.1-dev (cli) (built: Jan 20 2003 12:13:11) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies root@warpcore:/src/php4-STABLE-200301201030/sapi/cli> ./php -i | head -13 phpinfo() PHP Version => 4.3.1-dev System => Linux warpcore 2.2.20 #10 Sun Nov 17 22:46:16 CET 2002 i686 Build Date => Jan 20 2003 12:09:35 Configure Command => './configure' '--enable-force-cgi-redirect' '--with-mysql=/usr/local/mysql' '--with-config-file-path=../conf' '--enable-trans-sid' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => ../conf PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 20021010 Debug Build => no root@warpcore:/src/php4-STABLE-200301201030/sapi/cli> cat | ./php Warning: preg_replace_callback() [...]: Parameter mismatch, pattern is a string while replacement in an array. in - on line 11 -- "php5" CVS module: goosh@warpcore:/src/php5/sapi/cli> ./php -v PHP 5.0.0-dev (cli) (built: Jan 20 2003 11:49:51) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies goosh@warpcore:/src/php5/sapi/cli> ./php -i | head -13 phpinfo() PHP Version => 5.0.0-dev System => Linux warpcore 2.2.20 #10 Sun Nov 17 22:46:16 CET 2002 i686 Build Date => Jan 20 2003 11:46:03 Configure Command => './configure' '--enable-force-cgi-redirect' '--with-mysql=/usr/local/mysql' '--with-config-file-path=../conf' '--enable-trans-sid' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => ../conf PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 90021012 Debug Build => no goosh@warpcore:/src/php5/sapi/cli> cat | ./php Warning: preg_replace_callback() [...]: Parameter mismatch, pattern is a string while replacement in an array. in - on line 7 regards dtg [2003-01-20 00:29:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip To see if it's ZE2 issue or not..and also, provide a complete, short and self-contained example script so that we can easily reproduce the problem ourselves. [2003-01-19 17:16:03] [EMAIL PROTECTED] Probably this patch screwed up preg_replace_* functions: http://lists.php.net/article.php?group=php.cvs&article=18024 I need the functionality to pass a callback _method_ to preg_replace_callback(). It worked usually like this (in a class): $s = preg_replace_callback(, array(&$this, 'callbackmethod'), $s); Now "array" is forbidden. Is this your intention? How to access callback methods then? regards dtg -- Edit this bug report at http://bugs.php.net/?id=21758&edit=1
#22157 [NEW]: libtool: s%^.*/%%: No such file or directory
From: [EMAIL PROTECTED] Operating system: RH 6.2, RH 7.3 PHP version: 5CVS-2003-02-10 (dev) PHP Bug Type: Compile Failure Bug description: libtool: s%^.*/%%: No such file or directory Hi, libtool perishes in todays PHP5 CVS [root@orbiter php5]# cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) [root@orbiter php5]# uname -a Linux orbiter 2.4.18-3smp #1 SMP Thu Apr 18 06:59:55 EDT 2002 i686 unknown [root@orbiter php5]# cat config.nice #! /bin/sh # # Created by configure './configure' \ '--enable-force-cgi-redirect' \ '--with-config-file-path=../conf' \ '--with-zlib' \ "$@" [root@orbiter php5]# ./libtool --version ./libtool: s%^.*/%%: No such file or directory ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [root@orbiter php5]# make -j2 /bin/sh libtool --silent --mode=link gcc -export-dynamic -g-O2 [... ... ... ... ... ... etc.] /zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_mm.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php libtool: s%^.*/%%: No such file or directory libtool: s%^.*/%%: No such file or directory libtool: -e: command not found libtool: -e: command not found regards dtg -- Edit bug report at http://bugs.php.net/?id=22157&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22157&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22157&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22157&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22157&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22157&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22157&r=support Expected behavior: http://bugs.php.net/fix.php?id=22157&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22157&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22157&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22157&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22157&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22157&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22157&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22157&r=gnused
#22157 [Fbk->Opn]: libtool: s%^.*/%%: No such file or directory
ID: 22157 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RH 6.2, RH 7.3 PHP Version: 5CVS-2003-02-10 (dev) New Comment: >Snapshot or straight from CVS? Straight from CVS in a fresh directory >Do you have libtool 1.4.3 installed? Yes. [root@orbiter php5]# whereis libtool libtool: /usr/src/php5/libtool /usr/src/libart_lgpl-2.3.11/libtool /usr/src/libtool-1.4.3/libtool.m4 /usr/src/libtool-1.4.3/libtool /usr/bin/libtool /usr/local/bin/libtool /usr/share/libtool [root@orbiter php5]# ls -la /usr/bin/libtool lrwxrwxrwx1 root root 22 Feb 11 03:33 /usr/bin/libtool -> /usr/local/bin/libtool [root@orbiter php5]# /usr/bin/libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) regards dtg Previous Comments: [2003-02-10 18:53:13] [EMAIL PROTECTED] Snapshot or straight from CVS? Do you have libtool 1.4.3 installed? [2003-02-10 18:13:36] [EMAIL PROTECTED] Hi, libtool perishes in todays PHP5 CVS [root@orbiter php5]# cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) [root@orbiter php5]# uname -a Linux orbiter 2.4.18-3smp #1 SMP Thu Apr 18 06:59:55 EDT 2002 i686 unknown [root@orbiter php5]# cat config.nice #! /bin/sh # # Created by configure './configure' \ '--enable-force-cgi-redirect' \ '--with-config-file-path=../conf' \ '--with-zlib' \ "$@" [root@orbiter php5]# ./libtool --version ./libtool: s%^.*/%%: No such file or directory ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [root@orbiter php5]# make -j2 /bin/sh libtool --silent --mode=link gcc -export-dynamic -g-O2 [... ... ... ... ... ... etc.] /zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_mm.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php libtool: s%^.*/%%: No such file or directory libtool: s%^.*/%%: No such file or directory libtool: -e: command not found libtool: -e: command not found regards dtg -- Edit this bug report at http://bugs.php.net/?id=22157&edit=1
#22157 [Fbk->Csd]: libtool: s%^.*/%%: No such file or directory
ID: 22157 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: RH 6.2, RH 7.3 PHP Version: 5CVS-2003-02-10 (dev) New Comment: Ok, I've kicked all libtool, automake and autoconf RPMs from the RH6.2 and RH7.3 machines and installed the new versions of these programs from source. It worked then. Thanks for your efforts. regards dtg Previous Comments: [2003-02-10 20:57:22] [EMAIL PROTECTED] You're doing something wrong or I broke the damn libtool when I upgraded it in CVS. It looks like you've installed libtool pretty weirdly.. Are you sure it's not conflicting with some old version? And you should have libtool.m4 somehwere under /usr/share/libtool too. Basically the problem is that when you run buildconf (do ./cvsclean && ./buildconf) aclocal will add the contents of that libtool.m4 into your configure script. And that doesn't seem to happen now. Try running aclocal manually after buildconf to see if it outputs some error. [2003-02-10 20:42:17] [EMAIL PROTECTED] >Snapshot or straight from CVS? Straight from CVS in a fresh directory >Do you have libtool 1.4.3 installed? Yes. [root@orbiter php5]# whereis libtool libtool: /usr/src/php5/libtool /usr/src/libart_lgpl-2.3.11/libtool /usr/src/libtool-1.4.3/libtool.m4 /usr/src/libtool-1.4.3/libtool /usr/bin/libtool /usr/local/bin/libtool /usr/share/libtool [root@orbiter php5]# ls -la /usr/bin/libtool lrwxrwxrwx1 root root 22 Feb 11 03:33 /usr/bin/libtool -> /usr/local/bin/libtool [root@orbiter php5]# /usr/bin/libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) regards dtg [2003-02-10 18:53:13] [EMAIL PROTECTED] Snapshot or straight from CVS? Do you have libtool 1.4.3 installed? [2003-02-10 18:13:36] [EMAIL PROTECTED] Hi, libtool perishes in todays PHP5 CVS [root@orbiter php5]# cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) [root@orbiter php5]# uname -a Linux orbiter 2.4.18-3smp #1 SMP Thu Apr 18 06:59:55 EDT 2002 i686 unknown [root@orbiter php5]# cat config.nice #! /bin/sh # # Created by configure './configure' \ '--enable-force-cgi-redirect' \ '--with-config-file-path=../conf' \ '--with-zlib' \ "$@" [root@orbiter php5]# ./libtool --version ./libtool: s%^.*/%%: No such file or directory ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [root@orbiter php5]# make -j2 /bin/sh libtool --silent --mode=link gcc -export-dynamic -g-O2 [... ... ... ... ... ... etc.] /zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_objects.lo Zend/zend_object_handlers.lo Zend/zend_objects_API.lo Zend/zend_mm.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php libtool: s%^.*/%%: No such file or directory libtool: s%^.*/%%: No such file or directory libtool: -e: command not found libtool: -e: command not found regards dtg -- Edit this bug report at http://bugs.php.net/?id=22157&edit=1
#20517 [NEW]: Reopening bug #19113
From: [EMAIL PROTECTED] Operating system: RH Linux PHP version: 4.3.0RC1 PHP Bug Type: Apache related Bug description: Reopening bug #19113 The *critical* error described in #19113 still exists in 4.3.0RC1. Misuse of HTTPs CONNECT-header allows tunneling and relaying of various services (like e.g. SMTP in intranets). There are thousands of open relays outside due to this bug. regards dtg -- Edit bug report at http://bugs.php.net/?id=20517&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20517&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20517&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20517&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20517&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20517&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20517&r=support Expected behavior: http://bugs.php.net/fix.php?id=20517&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20517&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20517&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20517&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20517&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20517&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20517&r=isapi
#17098 [Com]: apache sending 304 - not modified header
ID: 17098
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+/* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+f->r->no_local_copy = 1;
+
+return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
Previous Comments:
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
[2002-10-18 05:43:08] [EMAIL PROTECTED]
Ok. We should do something about this bug, I suppose.
Mail from Ryou Takagi
= BEGIN
Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >>Summary: Apache2 sending 304 - not modified header
> >>http://bugs.php.net/bug.php?id=17098
> >>
> >>This is serious problem for serious sites.
> >>(Serious sites shouldn't use Apache2, though)
> >
> >
> > This looks like an Apache 2 bug, rather then aPHP one. I am
guessing the fix
> > they made did not work properly.
>
> Great!
> Then we can just wait their fix :)
I am afraid this is not the case. This is the report of the status.
As from Apache 2.0.40, the API of the filter registration functions
has changed. The changelog says:
--- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
*) Add a filter_init parameter to the filter registration functions
so that a filter can execute arbitrary code before the handlers
are invoked. This resolves a problem where mod_include requests
would incorrectly return a 304. [Justin Erenkrantz]
--- End quotation from Apache Changelog ---
And the current mod_include.c in Apache 2.0.43 source tree uses this
API like this:
--- From modules/filters/mod_include.c in Apache 2.0.43 source tree
---
static int includes_setup(ap_filter_t *f)
{
include_dir_config *conf =
(include_dir_config
*)ap_get_module_config(f->r->per_dir_config,
&include_module);
/* When our xbithack value isn't set to full or our platform isn't
* providing group-level protection bits or our group-level bits do
not
* have group-execite on, we will set the no_local_copy value to 1
so
* that we will not send 304s.
*/
if ((*conf->xbithack != xbithack_full)
|| !(f->r->finfo.valid & APR_FINFO_GPROT)
|| !(f->r->finfo.protection & APR_GEXECUTE)) {
f->r->no_local_copy = 1;
}
return OK;
}
/* Note from TAKAGI: several lines omitted */
static void register_hooks(apr_pool_t *p)
{
APR_REGISTER_OPTIONAL_FN(ap_ssi_get_tag_and_value);
APR_REGISTER_OPTIONAL_FN(ap_ssi_parse_string);
APR_REGISTER_OPTIONAL_FN(ap_register_include_handler);
#17098 [Com]: apache sending 304 - not modified header
ID: 17098
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
... and it's not fixed in 4.3.0 RC4 either...
Daniel
Previous Comments:
[2002-12-13 18:24:22] [EMAIL PROTECTED]
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+/* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+f->r->no_local_copy = 1;
+
+return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
[2002-10-18 05:43:08] [EMAIL PROTECTED]
Ok. We should do something about this bug, I suppose.
Mail from Ryou Takagi
= BEGIN
Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >>Summary: Apache2 sending 304 - not modified header
> >>http://bugs.php.net/bug.php?id=17098
> >>
> >>This is serious problem for serious sites.
> >>(Serious sites shouldn't use Apache2, though)
> >
> >
> > This looks like an Apache 2 bug, rather then aPHP one. I am
guessing the fix
> > they made did not work properly.
>
> Great!
> Then we can just wait their fix :)
I am afraid this is not the case. This is the report of the status.
As from Apache 2.0.40, the API of the filter registration functions
has changed. The changelog says:
--- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
*) Add a filter_init parameter to the filter registration functions
so that a filter can execute arbitrary code before the handlers
are invoked. This resolves a problem where mod_include requests
would incorrectly return a 304. [Justin Erenkrantz]
--- End quotation from Apache Changelog ---
And the current mod_include.c in Apache 2.0.43 source tree uses this
API like this:
--- From modules/filters/mod_include.c in Apache 2.0.43 source tree
---
static int includes_setup(ap_filter_t *f)
{
include_dir_config *conf =
(include_dir_config
*)ap_get_module_config(f->r->per_dir_config,
&include_module);
/* When our xbithack value isn't set to full or our platform isn't
* providing group-level protection bits or our group-level bits do
not
* have group-execite on, we will set the no_local_copy value to 1
so
* that we will not send 304s.
*/
if ((*conf->xbithack != xbithack_full)
|| !(f->r->finfo.valid & APR_FINFO_GPROT)
|| !(f->r->finfo.protection & APR_GEXECUTE)) {
f->r->no_local_copy = 1;
}
return OK;
}
/* Note from TAKAGI: several lines omitted */
static void register_hooks(apr_pool_t *p)
{
#17098 [Com]: apache sending 304 - not modified header
ID: 17098
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
... and the bug is present in 4.3.0 release.
Previous Comments:
[2002-12-25 18:03:55] [EMAIL PROTECTED]
... and it's not fixed in 4.3.0 RC4 either...
Daniel
[2002-12-13 18:24:22] [EMAIL PROTECTED]
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+/* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+f->r->no_local_copy = 1;
+
+return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
[2002-10-18 05:43:08] [EMAIL PROTECTED]
Ok. We should do something about this bug, I suppose.
Mail from Ryou Takagi
= BEGIN
Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >>Summary: Apache2 sending 304 - not modified header
> >>http://bugs.php.net/bug.php?id=17098
> >>
> >>This is serious problem for serious sites.
> >>(Serious sites shouldn't use Apache2, though)
> >
> >
> > This looks like an Apache 2 bug, rather then aPHP one. I am
guessing the fix
> > they made did not work properly.
>
> Great!
> Then we can just wait their fix :)
I am afraid this is not the case. This is the report of the status.
As from Apache 2.0.40, the API of the filter registration functions
has changed. The changelog says:
--- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
*) Add a filter_init parameter to the filter registration functions
so that a filter can execute arbitrary code before the handlers
are invoked. This resolves a problem where mod_include requests
would incorrectly return a 304. [Justin Erenkrantz]
--- End quotation from Apache Changelog ---
And the current mod_include.c in Apache 2.0.43 source tree uses this
API like this:
--- From modules/filters/mod_include.c in Apache 2.0.43 source tree
---
static int includes_setup(ap_filter_t *f)
{
include_dir_config *conf =
(include_dir_config
*)ap_get_module_config(f->r->per_dir_config,
&include_module);
/* When our xbithack value isn't set to full or our platform isn't
* providing group-level protection bits or our group-level bits do
not
* have group-execite on, we will set the no_local_copy value to 1
so
* that we will not send 304s.
*/
if ((*conf->xbithack != xbithack_full)
|| !(f->r->finfo.valid & APR_FINFO_GPROT)
|| !(f->r->finfo.protection & APR_GEXECUTE))
Bug #16970: Unable to load libphp_java.so - core_globals not found
From: [EMAIL PROTECTED] Operating system: Solairs 8 PHP version: 4.2.0 PHP Bug Type: Java related Bug description: Unable to load libphp_java.so - core_globals not found Configuration information: -- * System: Solaris 8 * PHP config: ./configure --prefix=/usr/local --enable-versioning --enable-libgcc --with-apxs=/usr/local/apache/bin/apxs --with-zlib=/usr/local --enable-bcmath --enable-debug --enable-magic-quotes --with-gdbm --with-mcrypt --with-mhash --with-mysql --with-ldap=/usr/local/openldap --with-pdflib --with-xml --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-gd --enable-xslt --with-xslt-sablot --with-dom=/usr/local/lib --with-java * Compiler and Java Versions: I tried several combinations gcc 2.95.3, gcc 3.0.4 java 1.3.1, java 1.4 * Problem: unreferenced symbol in libphp_java.so ldd -d /usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so symbol not found: core_globals (/usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so) Or seen from the apache error log (the php module loads and runs fine otherwise) PHP Warning: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so' - ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so: symbol core_globals: referenced symbol not found in Unknown on line 0 Sorry I am not a C programmer and can't hint at a solution. Certainly libphp_java.so is NOT looking for some other dynamic library it can't find ... I know that much :) -- Edit bug report at http://bugs.php.net/?id=16970&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16970&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16970&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16970&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16970&r=support Expected behavior: http://bugs.php.net/fix.php?id=16970&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16970&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16970&r=submittedtwice
Bug #16970 Updated: Unable to load libphp_java.so - core_globals not found
ID: 16970 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Java related -Operating System: Solairs 8 +Operating System: Solaris 8 PHP Version: 4.2.0 New Comment: I managed to get it work now, but don't know really why. Basically: - I installed/compiled all gnu tools (binutils 2.12, autoconf, automake all latest versions) - added the -with-gnu-ld option to php's configure. - recompiled apache too with the same gcc (3.0.4) Can't understand why it works now, since 'core_globals' is still missing from libphp_java.so if I look at it from 'ldd -d libphp_java.so' I also tried to compile with the workshop 6.0 update 2 compiler and got the same problem Previous Comments: [2002-05-02 12:25:48] [EMAIL PROTECTED] Configuration information: -- * System: Solaris 8 * PHP config: ./configure --prefix=/usr/local --enable-versioning --enable-libgcc --with-apxs=/usr/local/apache/bin/apxs --with-zlib=/usr/local --enable-bcmath --enable-debug --enable-magic-quotes --with-gdbm --with-mcrypt --with-mhash --with-mysql --with-ldap=/usr/local/openldap --with-pdflib --with-xml --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-gd --enable-xslt --with-xslt-sablot --with-dom=/usr/local/lib --with-java * Compiler and Java Versions: I tried several combinations gcc 2.95.3, gcc 3.0.4 java 1.3.1, java 1.4 * Problem: unreferenced symbol in libphp_java.so ldd -d /usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so symbol not found: core_globals (/usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so) Or seen from the apache error log (the php module loads and runs fine otherwise) PHP Warning: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so' - ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/php/extensions/debug-non-zts-20010901/libphp_java.so: symbol core_globals: referenced symbol not found in Unknown on line 0 Sorry I am not a C programmer and can't hint at a solution. Certainly libphp_java.so is NOT looking for some other dynamic library it can't find ... I know that much :) -- Edit this bug report at http://bugs.php.net/?id=16970&edit=1
#19645 [NEW]: Extended functionality for parse_ini_file
From: [EMAIL PROTECTED] Operating system: Linux RH6.2 PHP version: 4CVS-2002-09-27 PHP Bug Type: Feature/Change Request Bug description: Extended functionality for parse_ini_file Hi, this is not a bug report, it is a feature question. Would it be possible to extend the parse_ini_file() function not to read a configuration file line by line but to handle multiple lines for an entry? E.g. ; This is an .ini file FOO = "a short value" This works fine, but ; An other .ini file BAR = "a very long value that takes more then an other line and can't be displayed in a small terminal window" will return only the first line, which I think is not desired. What do you people think? regards dtg -- Edit bug report at http://bugs.php.net/?id=19645&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19645&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19645&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19645&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19645&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19645&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19645&r=support Expected behavior: http://bugs.php.net/fix.php?id=19645&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19645&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19645&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19645&r=globals
#15885 [Com]: thttpd can't serve 0 byte files with PHP patches
ID: 15885 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type:Other web server PHP Version: 4.1.2 New Comment: Sorry, I don't remember that password after 8 months. Hmm... file_address is still set to (char *)1... Anyway, it appears to be ok now. But I noticed another difference between thttpd with and without php4-latest. Plain thttpd 2.21b issues a 408 after exactly 1 minute when the client has not sent any request. With php4-latest the connection is just closed without any error and the time is sometimes as short as 4 seconds. My 2.22beta4 with (patched) PHP 4.1.2 reacts correctly like plain thttpd. Previous Comments: [2002-11-03 11:07:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-03-05 12:59:34] [EMAIL PROTECTED] PHP for thttpd sets TG(hc)->file_address = (char *)1 to mark a connection as "don't close". thttpd used this value to mark files without mapped memory (0 byte files). When such a file is requested, the client hangs. -- Edit this bug report at http://bugs.php.net/?id=15885&edit=1
Bug #15565: AND operation errors on datas from MySQL Table
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.1.1
PHP Bug Type: MySQL related
Bug description: AND operation errors on datas from MySQL Table
Hello
Can I submit a strange problem PHP / MySQL ?
>From a very simple table, 1 key ( BYTE ), 2 vars ( INTEGER )
I initialise two records whith some values.
I read the first var from first record and second var from second record.
I do the AND ( & ) functiun on the two vars and I get a wrong result.
I join my test script to my request.
Please send problem analysis to [EMAIL PROTECTED]
Best regards.
Functiun AND Check
No access to Data Base Server." );
exit();
}
if (! @mysql_select_db("BaseTest") )
{ echo( "No access to Data Base." );
exit();
}
// Table Création.
$sql = "CREATE TABLE TEST (
". " Num TINYINT UNSIGNED not null AUTO_INCREMENT,
". " V1 INT (10) UNSIGNED not null,
". " V2 INT (10) UNSIGNED not null,
". " PRIMARY KEY (Num),
". " UNIQUE (Num))
". " comment = 'Table de Test.';";
$crt = mysql_query($sql);
// First record create.
$x = 0X;
$sql = "INSERT INTO TEST SET
". " V1='$x';";
$ce = mysql_query($sql);
// Second record create.
$x = 0X0f0f0f0f;
$sql = "INSERT INTO TEST SET
". " V2='$x';";
$ce = mysql_query($sql);
// Vars initialisation .
$a = 0;
$b = 0;
// First record Read.
$rt = MYSQL_QUERY("SELECT V1 FROM TEST WHERE (Num = 1)") or
die("Erreur No: ".mysql_error());
$ct = mysql_fetch_array($rt);
if ($ct)
{ $a = $ct[V1];
}
mysql_free_result ($rt);
// Second record read.
$rt = MYSQL_QUERY("SELECT V2 FROM TEST WHERE (Num = 2)") or
die("Erreur No: ".mysql_error());
$ct = mysql_fetch_array($rt);
if ($ct)
{ $b = $ct[V2];
}
mysql_free_result ($rt);
// AND functiun on results and display.
$x = $a & $b;
echo ("Var A = ".DecBin($a)."");
echo ("Var B = ".DecBin($b)."");
echo ("AND Result = ".DecBin($x)."");
// Correct display for vars.
// Waiting AND Result =
// I get AND Result = 1100010101010011001
// Where the error is?.
?>
--
Edit bug report at http://bugs.php.net/?id=15565&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15565&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15565&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15565&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15565&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15565&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15565&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15565&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15565&r=submittedtwice
Bug #14988 Updated: mysql_pconnect() and POST takes a lot of time
ID: 14988
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating System: w2k
PHP Version: 4.1.1
New Comment:
seems to be caused by slow DNS-lookups and some problems in netscape
4.x:
http://www.phpbuilder.com/forum/read.php3?num=4&id=5321&thread=2583
Previous Comments:
[2002-01-11 05:26:44] [EMAIL PROTECTED]
did some further checks - i have the same problem with the cgi-version
and using older version (4.0.4) and when using mysql_connect instead of
mysql_pconnect.
my mysql-version is 3.23.46-nt
[2002-01-10 21:43:49] [EMAIL PROTECTED]
when using php 4.1.0 and 4.1.1 on win2k (both php4isapi.dll and
php4apache.dll)
the function-call
mysql_pconnect("localhost", "root", "")
takes about 5 seconds when the page is a called with a post request
() while there is no
noticable delay when calling it with a GET-request (by entering the url
pagename.php directly into the browser or setting method="get" in the
form-tag)
--
Edit this bug report at http://bugs.php.net/?id=14988&edit=1
Bug #15885: thttpd can't serve 0 byte files with PHP patches
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.2 PHP Bug Type: Other web server Bug description: thttpd can't serve 0 byte files with PHP patches PHP for thttpd sets TG(hc)->file_address = (char *)1 to mark a connection as "don't close". thttpd used this value to mark files without mapped memory (0 byte files). When such a file is requested, the client hangs. -- Edit bug report at http://bugs.php.net/?id=15885&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15885&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15885&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15885&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15885&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15885&r=support Expected behavior: http://bugs.php.net/fix.php?id=15885&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15885&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15885&r=submittedtwice
#22290 [Com]: curl seems to have problems sending https
ID: 22290 Comment by: daniel at haxx dot se Reported By: donauinsel at hotmail dot com Status: Feedback Bug Type: cURL related Operating System: W32/NT PHP Version: 4.3.1 New Comment: Please elaborate a lot more on the "seems to have problems" part. Previous Comments: [2003-02-19 04:18:37] [EMAIL PROTECTED] What was your previous PHP version? Are you sure you have upgraded ALL the old dlls with the new ones found in the 4.3.1 release package? [2003-02-19 01:41:49] donauinsel at hotmail dot com With older version of curl - no problems on connecting to https. maybe a problem of openssl or libeay32.dll ? -- Edit this bug report at http://bugs.php.net/?id=22290&edit=1
#27341 [Com]: CURLOPT_RETURNTRANSFER and CURLOPT_CUSTOMREQUEST incompatibility?
ID: 27341
Comment by: daniel at haxx dot se
Reported By: matteo at beccati dot com
Status: Bogus
Bug Type: cURL related
Operating System: Win32 - Linux
PHP Version: 4.3.4
New Comment:
I beg to differ.
CURLOPT_RETURNTRANSFER is not an option that libcurl provides, it is an
option that the PHP/CURL layer has invented and uses.
Thus, we cannot fix this in the curl project. It is not a curl bug!
Previous Comments:
[2004-02-21 04:10:55] matteo at beccati dot com
> Ask the curl author(s).
Done.
http://sourceforge.net/tracker/index.php?func=detail&aid=901648&group_id=976&atid=100976
> Not PHP bug (if it even is a bug which I doubt).
You're probabiliy correct saying that it's not a PHP bug, but it really
seems a wrong cURL behaviour to me.
When setting CURLOPT_RETURNTRANSFER I'm asking curl_exec to return the
result instead that outputting it, but result isn't returned, neither
printed out.
Thank you for your help.
[2004-02-21 02:57:08] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Not PHP bug (if it even is a bug which I doubt).
Ask the curl author(s).
[2004-02-21 02:41:18] matteo at beccati dot com
Description:
Trying to help a friend which wanted to do a curl HEAD request with php
(just like the shell curl -I does), I wrote down this code, without
much checking:
$ch = curl_init('http://foo/bar.html');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');
var_dump(curl_exec($ch));
In fact he tried it and told me it doesn't work, while this does:
$ch = curl_init('http://foo/bar.html');
//curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');
ob_start();
curl_exec($ch);
var_dump(ob_get_clean());
phpinfo() tels me that I'm running:
libcurl/7.10.5 OpenSSL/0.9.7b zlib/1.1.4
I've also seen bug #15279, but it was marked as documentation problem,
and didn't explain this weird issue.
Reproduce code:
---
$ch = curl_init('http://beccati.com/img/adv.png');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'HEAD');
var_dump(curl_exec($ch));
Expected result:
string(214) "HTTP/1.1 200 OK
Date: Sat, 21 Feb 2004 07:39:06 GMT
Server: Apache
Last-Modified: Wed, 06 Aug 2003 12:35:16 GMT
ETag: "27c64-204-3f30f604"
Accept-Ranges: bytes
Content-Length: 516
Content-Type: image/png
"
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=27341&edit=1
#22379 [Com]: bug introduced going from PHP 4.3.x to 4.3.1+
ID: 22379 Comment by: daniel at haxx dot se Reported By: jason at hdev dot net Status: Assigned Bug Type: cURL related Operating System: Windows 2000 PHP Version: 4.3.1 Assigned To: edink New Comment: This doesn't look like a bug but the expected behavior with libcurl 7.10 or later. As can be read with somewhat more details here: http://curl.haxx.se/lxr/source/SSLCERTS Previous Comments: [2003-02-24 22:52:28] [EMAIL PROTECTED] Did you replace _all_ existing extra dlls in your system from the dlls/ folder from the 4.3.1 package? [2003-02-24 19:45:17] jason at hdev dot net It was returning blank response when I used curl. [2003-02-24 19:44:20] jason at hdev dot net Actually I experienced the problem only with the extension, php_curl.dll in the php extensions folder. Simply replacing the dll with the version from 4.3.0 fixed the problem, so I suspected something wrong with one of the dlls. [2003-02-24 15:34:47] bharris at spro dot net WORKAROUND: Setting CURLOPT_SSL_VERIFYPEER to 0 will bypass error (and security). [2003-02-24 14:46:39] bharris at spro dot net That should read "without issue"... 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/22379 -- Edit this bug report at http://bugs.php.net/?id=22379&edit=1
#22517 [Com]: CURL does not work using curl_setopt($curl, CURLOPT_FILE, $fp);
ID: 22517
Comment by: daniel at haxx dot se
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: cURL related
Operating System: FreeBSD 4.7-(STABLE|RELEASE)
PHP Version: 4.3.0/4.3.1/4.3.2-dev
New Comment:
http://curl.haxx.se/docs/sslcerts.html
Previous Comments:
[2003-03-03 14:46:14] [EMAIL PROTECTED]
Still same problems with the latest php4 STABLE which I downloaded this
afternoon.
[EMAIL PROTECTED]:/usr/local/src/php4-STABLE-200303031230/sapi/cli# ./php
-v
PHP 4.3.2-dev (cli) (built: Mar 3 2003 21:54:28)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
with Zend Optimizer v2.1.0, Copyright (c) 1998-2003, by Zend
Technologies
[2003-03-03 13:35:24] [EMAIL PROTECTED]
Busy building the latest stable which I downloaded earlier today. Will
keep you guys posted on the status.
[2003-03-03 09:30:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-03-03 06:53:36] [EMAIL PROTECTED]
Hi,
I've written some ISP management software some time ago, and I've
upgraded two servers at home in preparation for a roll out on our
production servers, to test all our PHP code works.
Some of my scripts work via the CLI other work via the mod_php version
on apache 1.3.26 / 1.3.27 versions of apache. OpenSSL versions 0.9.6g
and 0.9.7 have been tested.
On php 4.2.3 with curl version's 7.9.8 and 7.10.3 I do not get this
problem. On 4.3.0 and 4.3.1 I have this error where (a) I don't get
anything data in the $fp file descriptor and (b) it's moans about the
following:
===
[EMAIL PROTECTED]:/usr/local/vweb/stats.ataris.co.za/data/cacti/scripts# php
uudial.php
* About to connect() to waggle.ops.uunet.co.za:443
* Connected to waggle.ops.uunet.co.za (196.7.0.184) port 443
* SSL: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Closing connection #0
SSL: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Array
(
[data] =>
[http_code] => 0
)
Cannot get UUnet Session ID
===
Tried using the following CURL SETOPT's:
* CURLOPT_SSL_VERIFYPEER
* CURLOPT_SSLVERSION
* CURLOPT_SSL_VERIFYHOST
Snipbit from my UUdial class function getSecureCookie.
$fp = tmpfile();
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $uunet_url);
curl_setopt($curl, CURLOPT_TIMEOUT, 20);
curl_setopt($curl, CURLOPT_FILE, $fp);
curl_setopt($curl, CURLOPT_USERPWD, $uunet['login']);
curl_setopt($curl, CURLOPT_PROXY, "http://192.168.10.254:3128/";);
curl_exec($curl);
$response['http_code'] = curl_getinfo($curl, CURLINFO_HTTP_CODE); /*
This is used to see if we get a HTTP 200 code */
rewind($fp);
while ($str = fgets($fp, 4096)) {
$pairs .= $str;
}
fclose($fp);
$response['data'] = $pairs;
asort($response);
if ($response['http_code'] == "200") {
preg_match ('//ims',
$response['data'], $n);
if ($n[1]) {
$this->cookie = $n[1];
} else {
die ("Cannot get UUnet Secure Cookie");
}
} else {
die ("Cannot get UUnet Secure Cookie");
}
--
Edit this bug report at http://bugs.php.net/?id=22517&edit=1
#22290 [Com]: curl seems to have problems sending https
ID: 22290 Comment by: daniel at haxx dot se Reported By: donauinsel at hotmail dot com Status: No Feedback Bug Type: cURL related Operating System: W32/NT PHP Version: 4.3.1 New Comment: I'd just like to mention that the documentation on curl and how to deal with certificate verification in libcurl 7.10 and later has a new "permanent" URL that is better to point to than the one previously mentioned in another bug report: http://curl.haxx.se/docs/sslcerts.html Previous Comments: [2003-03-13 05:04:51] black at flamingo dot ru Just found the answer in the next bug-report: http://bugs.php.net/bug.php?id=22379 [2003-03-13 04:37:35] black at flamingo dot ru I have the same problem - when I'm trying to retreive https:// content via cURL I'm getting "SSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed". When I go to the same urls with a browser - everything's Ok. http:// queries work just fine. I have PHP 4.3.1 newly installed so I'm absolutely sure I use libraries from 4.3.1 package. Here's code which causes the error (CGI under IIS): https://www.verisign.com/"; ; $ch = curl_init(); curl_setopt ($ch, CURLOPT_URL, $url); curl_setopt ($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (compatible; MSIE5.01; Windows NT 5.0)"); curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1); echo "|". curl_exec($ch)."|"; if (curl_errno($ch)) echo "ERROR: ".curl_error($ch); curl_close($ch); ?> Thanks [2003-02-25 02:08:22] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-19 17:00:32] daniel at haxx dot se Please elaborate a lot more on the "seems to have problems" part. [2003-02-19 04:18:37] [EMAIL PROTECTED] What was your previous PHP version? Are you sure you have upgraded ALL the old dlls with the new ones found in the 4.3.1 release package? 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/22290 -- Edit this bug report at http://bugs.php.net/?id=22290&edit=1
#32767 [NEW]: oracle connection not closing correctly
From: daniel at bitarts dot com
Operating system: solaris
PHP version: 5.0.4
PHP Bug Type: DBX related
Bug description: oracle connection not closing correctly
Description:
Dozens of connection threads are being created in oracle. They aren't
being removed.
Using Oracle 9, Apache 2
Reproduce code:
---
$link = dbx_connect ("oci8","","db","username","password")
or
die("Can't connect");
$result = dbx_close($link) or die ("Can't close");
Expected result:
Nothing, no die messages reported.
Actual result:
--
"Can't close"
--
Edit bug report at http://bugs.php.net/?id=32767&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32767&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32767&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32767&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32767&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32767&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32767&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32767&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32767&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32767&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32767&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32767&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32767&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32767&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32767&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32767&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32767&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32767&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32767&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32767&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32767&r=mysqlcfg
#33564 [NEW]: Strange behaviour passing long string to TRANSLATE in oracle
From: daniel at bitarts dot com Operating system: solaris PHP version: 5.0.4 PHP Bug Type: OCI8 related Bug description: Strange behaviour passing long string to TRANSLATE in oracle Description: Trying to insert data into an NCLOB field. I can do this by using a TRANSLATE in my sql, and binding variable with the OCIBindByName functions. However, when I pass a certain amount of characters, the update fails with this (incorrect) error: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported That amount of characters seems to be 2000. In the code below, if you change this line $data = str_pad($data, 2001, "a"); to $data = str_pad($data, 2000, "a"); It works fine. It's only when you try to insert more than 2000 characters you get this odd behaviour. Thank you. Daniel Reproduce code: --- $data = str_pad($data, 2001, "a"); $lob = OCINewDescriptor($conn, OCI_D_LOB); $stmt = OCIParse($conn,"UPDATE TEST SET NCLOB_TEST = TRANSLATE(:NCLOB_TEST USING NCHAR_CS) WHERE ID='1'"); OCIBindByName($stmt, ':NCLOB_TEST', &$lob, -1, OCI_B_CLOB); $lob->WriteTemporary($data); OCIExecute($stmt, OCI_DEFAULT); $lob->close(); $lob->free(); OCICommit($conn); Expected result: The NCLOB data field fills with 2001 "a" characters Actual result: -- error message: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported Nothing added to database. -- Edit bug report at http://bugs.php.net/?id=33564&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33564&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33564&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33564&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33564&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33564&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33564&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33564&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33564&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33564&r=support Expected behavior: http://bugs.php.net/fix.php?id=33564&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33564&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33564&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33564&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33564&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33564&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33564&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33564&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33564&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33564&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33564&r=mysqlcfg
#33564 [Opn]: Strange behaviour passing long string to TRANSLATE in oracle
ID: 33564 User updated by: daniel at bitarts dot com Reported By: daniel at bitarts dot com Status: Open Bug Type: OCI8 related Operating System: solaris PHP Version: 5.0.4 New Comment: I am using Oracle 9i Previous Comments: [2005-07-04 16:18:57] daniel at bitarts dot com Description: Trying to insert data into an NCLOB field. I can do this by using a TRANSLATE in my sql, and binding variable with the OCIBindByName functions. However, when I pass a certain amount of characters, the update fails with this (incorrect) error: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported That amount of characters seems to be 2000. In the code below, if you change this line $data = str_pad($data, 2001, "a"); to $data = str_pad($data, 2000, "a"); It works fine. It's only when you try to insert more than 2000 characters you get this odd behaviour. Thank you. Daniel Reproduce code: --- $data = str_pad($data, 2001, "a"); $lob = OCINewDescriptor($conn, OCI_D_LOB); $stmt = OCIParse($conn,"UPDATE TEST SET NCLOB_TEST = TRANSLATE(:NCLOB_TEST USING NCHAR_CS) WHERE ID='1'"); OCIBindByName($stmt, ':NCLOB_TEST', &$lob, -1, OCI_B_CLOB); $lob->WriteTemporary($data); OCIExecute($stmt, OCI_DEFAULT); $lob->close(); $lob->free(); OCICommit($conn); Expected result: The NCLOB data field fills with 2001 "a" characters Actual result: -- error message: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported Nothing added to database. -- Edit this bug report at http://bugs.php.net/?id=33564&edit=1
#33572 [NEW]: Behavior of foreach changed
From: daniel at bokko dot nl Operating system: Gentoo linux 2.4.22 PHP version: 4.3.11 PHP Bug Type: Arrays related Bug description: Behavior of foreach changed Description: After updrade to php 4.3.11 (from 4.3.4) the behaviour of foreach changed. When i do not specify a $key in the foreach statement, the value is wrong when it's an array. Reproduce code: --- Expected result: Array ( [0] => apple [1] => banana [2] => pear [3] => grape ) Array ( [0] => apple [1] => banana [2] => pear [3] => grape ) Actual result: -- Array ( [0] => Array ( [0] => apple [1] => banana [2] => pear [3] => grape ) [1] => 0 ) Array ( [0] => Array ( [0] => apple [1] => banana [2] => pear [3] => grape ) [1] => 1 ) -- Edit bug report at http://bugs.php.net/?id=33572&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33572&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33572&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33572&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33572&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33572&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33572&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33572&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33572&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33572&r=support Expected behavior: http://bugs.php.net/fix.php?id=33572&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33572&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33572&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33572&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33572&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33572&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33572&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33572&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33572&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33572&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33572&r=mysqlcfg
#33564 [Fbk->Opn]: Strange behaviour passing long string to TRANSLATE in oracle
ID: 33564 User updated by: daniel at bitarts dot com Reported By: daniel at bitarts dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: solaris PHP Version: 5.0.4 New Comment: Same things happens there too, when I add lots of characters. Seems to be a bug in oracle? Previous Comments: [2005-07-04 22:24:47] [EMAIL PROTECTED] And what if you try to do the same with SQLPlus? Do the same query work for you? [2005-07-04 16:20:41] daniel at bitarts dot com I am using Oracle 9i [2005-07-04 16:18:57] daniel at bitarts dot com Description: Trying to insert data into an NCLOB field. I can do this by using a TRANSLATE in my sql, and binding variable with the OCIBindByName functions. However, when I pass a certain amount of characters, the update fails with this (incorrect) error: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported That amount of characters seems to be 2000. In the code below, if you change this line $data = str_pad($data, 2001, "a"); to $data = str_pad($data, 2000, "a"); It works fine. It's only when you try to insert more than 2000 characters you get this odd behaviour. Thank you. Daniel Reproduce code: --- $data = str_pad($data, 2001, "a"); $lob = OCINewDescriptor($conn, OCI_D_LOB); $stmt = OCIParse($conn,"UPDATE TEST SET NCLOB_TEST = TRANSLATE(:NCLOB_TEST USING NCHAR_CS) WHERE ID='1'"); OCIBindByName($stmt, ':NCLOB_TEST', &$lob, -1, OCI_B_CLOB); $lob->WriteTemporary($data); OCIExecute($stmt, OCI_DEFAULT); $lob->close(); $lob->free(); OCICommit($conn); Expected result: The NCLOB data field fills with 2001 "a" characters Actual result: -- error message: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported Nothing added to database. -- Edit this bug report at http://bugs.php.net/?id=33564&edit=1
#33564 [Bgs->Opn]: Strange behaviour passing long string to TRANSLATE in oracle
ID: 33564 User updated by: daniel at bitarts dot com Reported By: daniel at bitarts dot com -Status: Bogus +Status: Open Bug Type: OCI8 related Operating System: solaris PHP Version: 5.0.4 New Comment: I had made a mistake, TRANSLATE only works for NVARCHAR's etc and anything less than 2000 characaters. What I should be using is TO_NCHAR. This works fine in sql: UPDATE TEST SET NCLOB_BACKUP = TO_NCLOB(:NCLOB_BACKUP) WHERE ID='4 However, running this through php causes php to lock up: $data = "TEst2"; $lob = OCINewDescriptor($conn, OCI_D_LOB); $stmt = OCIParse($conn,"UPDATE TEST SET NCLOB_BACKUP = TO_NCLOB(:NCLOB_BACKUP) WHERE ID='4'"); OCIBindByName($stmt, ':NCLOB_BACKUP', &$lob, -1, OCI_B_CLOB); $lob->WriteTemporary($data); OCIExecute($stmt, OCI_DEFAULT); $lob->close(); $lob->free(); OCICommit($conn); I'm not too sure if it is an oracle bug anymore, or if it is, php should respond to it better? Thanks Previous Comments: [2005-07-05 11:35:20] [EMAIL PROTECTED] Or some kind of your mistake, I'm not sure how to classify it. So it doesn't look like PHP-only problem and I'm closing this report as bogus. Feel free to reopen it if/when you have more info. ---- [2005-07-05 11:23:34] daniel at bitarts dot com Same things happens there too, when I add lots of characters. Seems to be a bug in oracle? [2005-07-04 22:24:47] [EMAIL PROTECTED] And what if you try to do the same with SQLPlus? Do the same query work for you? ---- [2005-07-04 16:20:41] daniel at bitarts dot com I am using Oracle 9i ---- [2005-07-04 16:18:57] daniel at bitarts dot com Description: Trying to insert data into an NCLOB field. I can do this by using a TRANSLATE in my sql, and binding variable with the OCIBindByName functions. However, when I pass a certain amount of characters, the update fails with this (incorrect) error: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported That amount of characters seems to be 2000. In the code below, if you change this line $data = str_pad($data, 2001, "a"); to $data = str_pad($data, 2000, "a"); It works fine. It's only when you try to insert more than 2000 characters you get this odd behaviour. Thank you. Daniel Reproduce code: --- $data = str_pad($data, 2001, "a"); $lob = OCINewDescriptor($conn, OCI_D_LOB); $stmt = OCIParse($conn,"UPDATE TEST SET NCLOB_TEST = TRANSLATE(:NCLOB_TEST USING NCHAR_CS) WHERE ID='1'"); OCIBindByName($stmt, ':NCLOB_TEST', &$lob, -1, OCI_B_CLOB); $lob->WriteTemporary($data); OCIExecute($stmt, OCI_DEFAULT); $lob->close(); $lob->free(); OCICommit($conn); Expected result: The NCLOB data field fills with 2001 "a" characters Actual result: -- error message: Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-12703: this character set conversion is not supported Nothing added to database. -- Edit this bug report at http://bugs.php.net/?id=33564&edit=1
#31612 [Com]: No error message returned from curl_error() when connection fails by IP.
ID: 31612
Comment by: daniel at haxx dot se
Reported By: brian dot sanders at cometsystems dot com
Status: Open
Bug Type: cURL related
Operating System: Fedora Core 3
PHP Version: 5.0.2
New Comment:
This may in fact depend on what error message libcurl reports back, and
then this may change depending on what libcurl version you use. There
are/were in fact times when libcurl doesn't return an error message
(which is considered a bug).
Unless the PHP/curl binding is modified to use the curl_easy_strerror()
function.
Previous Comments:
[2005-01-19 17:02:15] brian dot sanders at cometsystems dot com
Description:
When requesting a file from a bad IP (in this case 127.0.0.1, with no
Web server running) cURL fails to retreive a page (as expected.)
curl_errno() returns an error code of 7, but curl_error returns NULL.
Reproduce code:
---
http://127.0.0.1');
$result = curl_exec($ch);
print('Error code: '.curl_errno($ch)."\n");
print('Error message: '.curl_error($ch)."\n");
?>
Expected result:
7
Failed to connect (or some such error)
Actual result:
--
7
--
Edit this bug report at http://bugs.php.net/?id=31612&edit=1
#25203 [NEW]: php -a doesn't work on windows
From: daniel at port dot as Operating system: windoze (all versions) PHP version: 4.3.3RC4 PHP Bug Type: Scripting Engine problem Bug description: php -a doesn't work on windows Description: Interactive mode (php -a) doesn't seem to work on windows. File mode works fine. I've tried various versions of windows and PHP, but the result is the same. Interactive mode works fine in Linux. Reproduce code: --- C:\PHP>php -a Interactive mode enabled ^C Expected result: working? Actual result: -- -- Edit bug report at http://bugs.php.net/?id=25203&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25203&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25203&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25203&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25203&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25203&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25203&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25203&r=support Expected behavior: http://bugs.php.net/fix.php?id=25203&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25203&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25203&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25203&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25203&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25203&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25203&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25203&r=gnused
#25203 [Bgs]: php -a doesn't work on windows
ID: 25203 User updated by: daniel at port dot as Reported By: daniel at port dot as Status: Bogus Bug Type: Scripting Engine problem Operating System: Any (ZTS enabled) PHP Version: 4.3.3RC5-dev New Comment: The behavior isn't consistant between the windows and linux versions. Under PHP 4.3.2 in windows using ^Z for EOF I get: C:\Program Files\nusphere\phpED\php>php -aq Interactive mode enabled ^Z ^Z test¨ C:\Program Files\nusphere\phpED\php> So now the php code executes (after ^Z ^Z), but then exits. I only used ^C in my example previously to exit interactive php. In linux, php -a will execute any php statement without exiting. Previous Comments: [2003-08-22 03:06:44] [EMAIL PROTECTED] It works just fine here, if you don't interupt the program with ^C but use proper windows EOF char which is ^Z. [2003-08-22 02:28:58] [EMAIL PROTECTED] I could reproduce this with latest stable CVS too. Did you try any older PHP releases? (4.3.2 for example) Does this problem exist with those? [2003-08-22 00:04:05] daniel at port dot as Description: Interactive mode (php -a) doesn't seem to work on windows. File mode works fine. I've tried various versions of windows and PHP, but the result is the same. Interactive mode works fine in Linux. Reproduce code: --- C:\PHP>php -a Interactive mode enabled ^C Expected result: working? Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=25203&edit=1
#26297 [NEW]: Function redeclare
From: daniel at cyberprune dot com
Operating system: Linux
PHP version: 4.3.4
PHP Bug Type: Scripting Engine problem
Bug description: Function redeclare
Description:
Fatal error: Cannot redeclare get_total_topics() (previously declared in
/vhost/rollo/rollo.cyberprune.com/portal/exoops/modules/newbb_plus/functions.php:2)
in
/vhost/rollo/rollo.cyberprune.com/portal/exoops/modules/newbb_plus/functions.php
on line 2
Reproduce code:
---
query($sql)) {
return(_ERROR);
}
if (!$myrow = $db->fetch_array($result)) {
return(_ERROR);
}
return($myrow['total']); }
Expected result:
Function to work
--
Edit bug report at http://bugs.php.net/?id=26297&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26297&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26297&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26297&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26297&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26297&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26297&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26297&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26297&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26297&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26297&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26297&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26297&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26297&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26297&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26297&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26297&r=float
#26297 [Opn->Bgs]: Function redeclare
ID: 26297
User updated by: daniel at cyberprune dot com
Reported By: daniel at cyberprune dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4.3.4
New Comment:
Found problem
Previous Comments:
[2003-11-18 04:52:07] daniel at cyberprune dot com
Description:
Fatal error: Cannot redeclare get_total_topics() (previously declared
in
/vhost/rollo/rollo.cyberprune.com/portal/exoops/modules/newbb_plus/functions.php:2)
in
/vhost/rollo/rollo.cyberprune.com/portal/exoops/modules/newbb_plus/functions.php
on line 2
Reproduce code:
---
query($sql)) {
return(_ERROR);
}
if (!$myrow = $db->fetch_array($result)) {
return(_ERROR);
}
return($myrow['total']); }
Expected result:
Function to work
--
Edit this bug report at http://bugs.php.net/?id=26297&edit=1
#27616 [Com]: Using Objects with Constructors/Destructors - Filesystem Delete Issues
ID: 27616 Comment by: daniel at haxx dot se Reported By: [EMAIL PROTECTED] Status: Open Bug Type: cURL related Operating System: Linux 2.4.22 PHP Version: 5CVS-2004-03-16 (dev) New Comment: Unfortunately, libcurl doesn't provide a rich enough API for the COOKIEJAR/COOKIEFILE to get stored in memory or similar. That is still in the TODO for the library. Until that happens, getting the jar written to a file is the only supported way. Previous Comments: [2004-03-16 19:08:31] [EMAIL PROTECTED] Description: When you create more than one Cookie Jar file using cURL, and using an object with a constructor and destructor to create/delete the temporary file, only one of the two cookie jar files is deleted, even though the destructor reports that deletion of both was successful. If you find any website that requires you to login, you should be able to reproduce this. Personally, I think there needs to be an option to use PHP writable streams for the COOKIEJAR/COOKIEFILE cURL Options, to allow more freedom to store the data. I would hope that would allow you to store the cookies in memory while the page executes, and have them cleared from memory once the request has completed successfully. Reproduce code: --- http://www.nightsys.net/cookiebugs/ This URL has all the source code required. Expected result: Both Cookie Jars to be deleted. Actual result: -- Only one of the two cookie jars are deleted. If you tell it to just unset one of the two objects, and only make 2 of the 3 cURL requests, the jar is removed. It only seems to be an issue when two are unset one after the other. -- Edit this bug report at http://bugs.php.net/?id=27616&edit=1
#28165 [NEW]: Missing implicit object to integer conversion
From: daniel at rozsnyo dot com Operating system: WinXP PHP version: 5CVS-2004-04-26 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: Missing implicit object to integer conversion Description: While the docs says that i can use use objects as needle, i actually can not - it might be missing some implicit conversion to integer from objects. (I use the published RC2 version (for win32), not the CVS version, the RC2 option is not available in the listbox for posting a bug-report) Another problem is the notice (in RC1 there was no notice, here is a notice... so I am posting as bug... by the way, it would be nice to have functions like __toInteger() [in_array], __toArray() [for] besides the known __toString [echo,print] Daniel Reproduce code: --- Expected result: I am expecting this result: --- Object id #4 NOT there Actual result: -- Look to notices: --- Object id #4 Notice: Object of class A could not be converted to integer in C:\www\default\test\index.php on line 9 Notice: Object of class A could not be converted to integer in C:\www\default\test\index.php on line 9 There -- Edit bug report at http://bugs.php.net/?id=28165&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28165&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28165&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28165&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28165&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28165&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28165&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28165&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28165&r=support Expected behavior: http://bugs.php.net/fix.php?id=28165&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28165&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28165&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28165&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28165&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28165&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28165&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28165&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28165&r=float
#28206 [NEW]: zlib.output_compression=on do garbage output
From: daniel at chatologica dot com Operating system: RedHat7.1 PHP version: 4.3.6 PHP Bug Type: Zlib Related Bug description: zlib.output_compression=on do garbage output Description: If I set in php.ini zlib.output_compression = On the php scripts will produce garbage output in the browser. The same php.ini configuration but with php v4.3.4 work good. Zlib 1.1.4 enabled -- Edit bug report at http://bugs.php.net/?id=28206&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28206&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28206&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28206&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28206&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28206&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28206&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28206&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28206&r=support Expected behavior: http://bugs.php.net/fix.php?id=28206&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28206&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28206&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28206&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28206&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28206&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28206&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28206&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28206&r=float
