#47206 [NEW]: Unintended API change in XSLTProcessor
From: nfor...@php.net Operating system: Linux PHP version: 5.3CVS-2009-01-24 (snap) PHP Bug Type: XSLT related Bug description: Unintended API change in XSLTProcessor Description: In 5.3, attempting to extend XSLTProcessor in the same way as in 5.2 (with type hinting on the method parameters) yields an E_STRICT message: "Declaration of ExtendedXSLTProcessor::importStylesheet() should be compatible with that of XSLTProcessor::importStylesheet()". Removing the type hint fixes the problem in 5.3. I am assuming this behavior is unintentional, and that the type hint should still be associated with the methods. This applies to both ::importStylesheet() and ::transformToDoc(), and potentially other methods as well. Reproduce code: --- Actual result: -- Strict Standards: Declaration of ExtendedXSLTProcessor::importStylesheet() should be compatible with that of XSLTProcessor::importStylesheet() in /.../test.php on line 8 -- Edit bug report at http://bugs.php.net/?id=47206&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47206&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47206&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47206&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47206&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47206&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47206&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47206&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47206&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47206&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47206&r=support Expected behavior: http://bugs.php.net/fix.php?id=47206&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47206&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47206&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47206&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47206&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47206&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47206&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47206&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47206&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47206&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47206&r=mysqlcfg
#47205 [NEW]: php_mysql crashes apache
From: marcos dot x86 at hotmail dot com
Operating system: Windows XP SP3
PHP version: 5.2.8
PHP Bug Type: Apache2 related
Bug description: php_mysql crashes apache
Description:
The Apache 2.2.11 crashes after any PHP script that uses a MySQL
function, like mysql_select_db. The crash report says about
php5ts.dll being crashed.
Reproduce code:
---
1. Have a MySQL 5.1.30 running.
2. Have a Apache 2.2.11 running, with PHP 5.2.8.
3. (here we check that both MySQL\bin and PHP are in PATH)
4. Run any MySQL+PHP script (in my case, Joomla installation).
5. Apache reports crashing twice, and the browser goes on server error.
Sample Code:
mysql_connect();
mysql_select_db("test");
(Yes, it crashes.)
Expected result:
Flawless Joomla setup or blank page for the code supplied.
Actual result:
--
Apache crashing against php5ts.dll
--
Edit bug report at http://bugs.php.net/?id=47205&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47205&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47205&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47205&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47205&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47205&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47205&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47205&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47205&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47205&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47205&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47205&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47205&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47205&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47205&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47205&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47205&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47205&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47205&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47205&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47205&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47205&r=mysqlcfg
#47204 [Opn]: Missing support for CURLOPT_IOCTLFUNCTION
ID: 47204
User updated by: a...@php.net
Reported By: a...@php.net
Status: Open
Bug Type: cURL related
Operating System: Irrelevant
PHP Version: 5.2.8
New Comment:
The same problem without PHP callback, using CURLOPT_READDATA to read
request body from a file:
http://www.example.com/digest/');
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Length: ' .
filesize('./postdata')));
curl_setopt($ch, CURLOPT_READDATA, fopen('./postdata', 'rb'));
if (!curl_exec($ch)) {
echo 'Error #' . curl_errno($ch) . ': ' . curl_error($ch);
}
?>
This also prints "Error #65: necessary data rewind wasn't possible"
Previous Comments:
[2009-01-23 23:28:24] a...@php.net
Description:
PHP's cURL extension allows using a callback for reading the request
body via CURLOPT_READFUNCTION, but it doesn't provide a way to set a
CURLOPT_IOCTLFUNCTION callback for rewinding the request body.
This rewinding may be needed when doing a POST or PUT HTTP request to
resource protected by Digest authentication.
Reproduce code:
---
= strlen($data)) {
return '';
}
$string = substr($data, $position, $length);
$position += strlen($string);
return $string;
}
$ch = curl_init();
curl_setopt($ch, CURLOPT_POST, true);
// This should be some URL protected by HTTP digest auth!
curl_setopt($ch, CURLOPT_URL, 'http://www.example.com/digest/');
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_setopt($ch, CURLOPT_READFUNCTION, 'read_callback');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Length: ' .
strlen($data)));
if (!curl_exec($ch)) {
echo 'Error #' . curl_errno($ch) . ': ' . curl_error($ch);
}
?>
Expected result:
Request should proceed.
Actual result:
--
Error #65: necessary data rewind wasn't possible
--
Edit this bug report at http://bugs.php.net/?id=47204&edit=1
#47204 [NEW]: Missing support for CURLOPT_IOCTLFUNCTION
From: a...@php.net
Operating system: Irrelevant
PHP version: 5.2.8
PHP Bug Type: cURL related
Bug description: Missing support for CURLOPT_IOCTLFUNCTION
Description:
PHP's cURL extension allows using a callback for reading the request body
via CURLOPT_READFUNCTION, but it doesn't provide a way to set a
CURLOPT_IOCTLFUNCTION callback for rewinding the request body.
This rewinding may be needed when doing a POST or PUT HTTP request to
resource protected by Digest authentication.
Reproduce code:
---
= strlen($data)) {
return '';
}
$string = substr($data, $position, $length);
$position += strlen($string);
return $string;
}
$ch = curl_init();
curl_setopt($ch, CURLOPT_POST, true);
// This should be some URL protected by HTTP digest auth!
curl_setopt($ch, CURLOPT_URL, 'http://www.example.com/digest/');
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_setopt($ch, CURLOPT_READFUNCTION, 'read_callback');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Length: ' .
strlen($data)));
if (!curl_exec($ch)) {
echo 'Error #' . curl_errno($ch) . ': ' . curl_error($ch);
}
?>
Expected result:
Request should proceed.
Actual result:
--
Error #65: necessary data rewind wasn't possible
--
Edit bug report at http://bugs.php.net/?id=47204&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47204&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47204&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47204&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47204&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47204&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47204&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47204&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47204&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47204&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47204&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47204&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47204&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47204&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47204&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47204&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47204&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47204&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47204&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47204&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47204&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47204&r=mysqlcfg
#47203 [NEW]: Error loading dynamic libraries with Apache 2.2.11
From: imchillindave at hotmail dot com Operating system: Windows XP PRO SP3 PHP version: 5.2.8 PHP Bug Type: Dynamic loading Bug description: Error loading dynamic libraries with Apache 2.2.11 Description: Hey there, I had this issue with a few dynamic libraries in the previous version of PHP, but there's more of them not loading in the latest version and I can't seem to find the fix for it. I used the installer to install PHP 5.2.8 as a new install with only Apache 2.2.11 already installed just shortly prior to installing PHP 5. I checked the Apache error log and there are several lines like this: PHP Warning: PHP Startup: Unable to load dynamic library 'C:\\Apache2.2\\PHP\\ext\\php_pgsql.dll' - The specified module could not be found.\r\n in Unknown on line 0 It cannot load these libraries: php_fdf.dll php_interbase.dll php_mcrypt.dll php_mhash.dll php_mysql.dll php_mysqli.dll php_oci8.dll php_pdo_firebird.dll php_pdo_mysql.dll php_pdo_oci.dll php_pdo_oci8.dll php_pdo_pgsql.dll php_pdo_sqlite_external.dll php_pgsql.dll php_pspell.dll php_sybase_ct.dll I downloaded the zip version of PHP 5.2.8 and tried replacing the "ext" directory with the one contained in the ZIP download and that didn't help. I verified the extension directory path is correct by looking at the phpinfo. The best I can tell is there's an issue with the dynamic library versions and so far I've had no luck at finding the solution for this problem. These are all dynamic library files included in your php installation files. Reproduce code: --- N/A. -- Edit bug report at http://bugs.php.net/?id=47203&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47203&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47203&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47203&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47203&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47203&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47203&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47203&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47203&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47203&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47203&r=support Expected behavior: http://bugs.php.net/fix.php?id=47203&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47203&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47203&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47203&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47203&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47203&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47203&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47203&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47203&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47203&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47203&r=mysqlcfg
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: onehourlate at hotmail dot com Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.6 Assigned To: scottmac New Comment: Unfortunately, libmysql.dll 5.1.30 seems crash. see #46842. I don't know if this crash is necesserally php related, but it's still useful to investigate because trying to ship a version of libmysql.dll that finally solves this bug would be a good thing Previous Comments: [2008-12-29 18:18:42] chaz_meister_rock at yahoo dot com In case anyone is wondering how to fix this, comments above give a workaround. I'll lay out the steps for the newbies: 1) Download PHP v5.1.6 from http://museum.php.net/php5/php-5.1.6-Win32.zip 2) Extract that zip and replace the "libmysql.dll" in your production PHP directory (probably c:\php) with the newly downloaded libmysql.dll. This worked successfully on Windows2003 PHP v5.2.8 Threadsafe. Also, for some reason, many other versions of libmysql.dll (either bundled with PHP or released with MySQL server) do not work correctly. Cheers [2008-12-15 22:47:56] chaz_meister_rock at yahoo dot com This is still broken in 5.2.8 [2008-12-14 00:52:45] paul at orac dot clara dot co dot uk Sadly, the clueless PHP folks have distributed the still broken 5.0.51a version of LIBMYSQL.DLL with PHP 5.2.8 LIBMYSQL.DLL 5.1.30 had been out for 3 weeks before this. You would have thought they'd have got a grip on this by now. How pathetic. [2008-11-30 11:07:38] paul at orac dot clara dot co dot uk This seems fixed at long last by copying over the Libmysql.dll file supplied with MySQL 5.1.30 Hopefully that will be in the next PHP release. [2008-11-26 21:27:45] cahlquist at yesco dot com We have the same problem, 5 to 6 second delay. We have commented out every single extension except php_mysql.dll and we get the delay. Then as soon as we comment out php_mysql.dll the problem goes away. PHP 5.2.6 Running on Microsoft Windows Server 2003 R2 IIS 6.0 CGI (NOT Fast CGI) 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#46896 [Bgs]: stream_get_meta_data() does not fill header list
ID: 46896
User updated by: christian dot lefebvre at atosorigin dot com
Reported By: christian dot lefebvre at atosorigin dot com
Status: Bogus
Bug Type: cURL related
Operating System: linux
PHP Version: 5.2.8
New Comment:
I disagree with the Bogus status.
As I have a workaround, this problem has a low priority for me, but I
consider it as a regression (see preceding comment).
Previous Comments:
[2008-12-18 20:44:30] christian dot lefebvre at atosorigin dot com
Sorry, but in the given example, the call to the function returns a
meta_data element with an EMPTY header sub-array despite the remote
server do returns headers.
The expected result is an array with header lines, and that's done only
if you use fread BEFORE.
[2008-12-18 20:31:17] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The function always puts the headers into the wrapper_data element,
this
is consistent with PHP 5.1.2 and 5.3.0.
The position of the fread() does not make any difference in the
output.
[2008-12-18 11:37:27] j...@php.net
See also bug #45092 (quite likely related)
[2008-12-18 10:22:33] christian dot lefebvre at atosorigin dot com
Description:
With php 5.2.8 and curlwrapper option, after calling fopen() on a
remote url, a call to stream_get_meta_data() returns an empty header
list.
If a call to fread() is inserted between fopen() and
stream_get_meta_data(), the headers are presents.
The problem appears during a migration from 5.0 without curl, to 5.2
with curl, so it seems curl related.
Calling the test script via strace shows that the socket is opened, but
there's no call to read() syscall before the stream_get_meta_data is
called.
The problem is not systematically reproduced (certainly due to response
latencies), but appears very often.
Reproduce code:
---
this version fails :
$src = fopen("http://www.perdu.com";, 'r');
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
$data= fread($src, 500);
echo $data."\n\n";
this one works (just call fread before get_meta) :
$src = fopen("http://www.perdu.com";, 'r');
$data= fread($src, 500);
$meta = stream_get_meta_data($src);
var_dump($meta);
var_dump($http_response_header);
echo $data."\n\n";
Expected result:
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(8) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Thu, 18 Dec 2008 10:15:19 GMT"
[2]=>
string(14) "Server: Apache"
[3]=>
Actual result:
--
array(10) {
["wrapper_data"]=>
array(2) {
["headers"]=>
array(0) {
}
...
--
Edit this bug report at http://bugs.php.net/?id=46896&edit=1
#47202 [NEW]: FTP fopen wrapper and # in file names
From: smlerman at gmail dot com
Operating system: Any
PHP version: 5.2.8
PHP Bug Type: FTP related
Bug description: FTP fopen wrapper and # in file names
Description:
It seems that the FTP fopen wrapper truncates file names when it
encounters a pound sign (#). The FTP server's log shows a request for
"file".
I have tried replacing the # with %23 (the result of urlencode), but the
server sees that as a request for "file%231.txt".
Reproduce code:
---
// Use fopen wrapper
$data = file_get_contents("ftp://username:passw...@ftp.example.com/file
#1.txt");
var_dump(strlen($data));
// Use ftp_* functions
$conn = ftp_connect('ftp.example.com');
ftp_login($conn, 'username', 'password');
ftp_get($conn, 'C:\\test.txt', 'file#1.txt', FTP_BINARY);
var_dump(filesize('C:\\test.txt'));
Expected result:
int(7)
int(7)
Actual result:
--
Warning: file_get_contents(ftp://@ftp.example.com/file#1.txt) [function.file-get-contents]: failed
to open stream: FTP server reports 550 /file : The system cannot find the
path specified. in...
int(0)
int(7)
--
Edit bug report at http://bugs.php.net/?id=47202&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47202&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47202&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47202&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47202&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47202&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47202&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47202&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47202&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47202&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47202&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47202&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47202&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47202&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47202&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47202&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47202&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47202&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47202&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47202&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47202&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47202&r=mysqlcfg
#47192 [Opn]: gethostbyname is not interruptible by signals
ID: 47192
User updated by: fmassei at gmail dot com
Reported By: fmassei at gmail dot com
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: Network related
Operating System: linux
PHP Version: 5.2.8
New Comment:
Somehow I posted this bug in the wrong category. It's not a
"Feature/Change Request" but more a "Network related" bug.
Previous Comments:
[2009-01-22 18:13:35] fmassei at gmail dot com
Description:
gethostbyname() is not interruptible by signals. If it cannot resolve
an hostname there is no way it can be interrupted except for a SIGKILL.
Reproduce code:
---
declare(ticks=1);
function al($sig)
{
echo $sig;
exit(0);
}
pcntl_signal(SIGINT, "al");
pcntl_signal(SIGTERM, "al");
pcntl_signal(SIGALRM, "al");
pcntl_alarm(3);
echo gethostbyname("google.com");
Expected result:
I was expected to interrupt gethostbyname() with any signal.
Actual result:
--
When running the above code, if the system cannot resolve google's
hostname, the function blocks and doesn't respond to any signal.
--
Edit this bug report at http://bugs.php.net/?id=47192&edit=1
#47199 [NEW]: pg_delete fails on NULL
From: andrew at labyrinth-it dot co dot uk Operating system: Linux (Fedora) PHP version: 5.2.8 PHP Bug Type: PostgreSQL related Bug description: pg_delete fails on NULL Description: pg_delete uses incorrect syntax for NULL columns. The code generated compares values with "col = NULL" instead of "col IS NULL". As a result, the row is not matched so is not deleted. Reproduce code: --- 1 [col1] => ) DELETE FROM demo WHERE id=1 AND col1 IS NULL; Actual result: -- When this runs, the second loop displays results for tables that have NULL columns at the start of the run. --- Array ( [id] => 1 [col1] => ) DELETE FROM demo WHERE id=1 AND col1=NULL; Array ( [id] => 1 [col1] => ) -- Edit bug report at http://bugs.php.net/?id=47199&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47199&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47199&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47199&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47199&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47199&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47199&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47199&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47199&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47199&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47199&r=support Expected behavior: http://bugs.php.net/fix.php?id=47199&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47199&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47199&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47199&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47199&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47199&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47199&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47199&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47199&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47199&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47199&r=mysqlcfg
#47198 [NEW]: pcntl_signal needs declare(ticks) which is deprecated since 5.3
From: me at thomaskeller dot biz Operating system: Linux PHP version: 5.3.0alpha3 PHP Bug Type: PCNTL related Bug description: pcntl_signal needs declare(ticks) which is deprecated since 5.3 Description: To state the PHP docs on register_tick_function (http://de2.php.net/manual/en/function.register-tick-function.php): "5.3.0 Ticks are now deprecated and register_tick_function() now throws an E_DEPRECATED notice." However, ticks are needed for pcntl_signal to process signal interrupts (pcntl_signal uses them since 4.3). Deprecating ticks will make cli scripts written in PHP pretty much useless if there is no signal handling available. The documentation also misses to outline alternatives for signal handling from 5.3 onwards. Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=47198&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47198&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47198&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47198&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47198&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47198&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47198&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47198&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47198&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47198&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47198&r=support Expected behavior: http://bugs.php.net/fix.php?id=47198&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47198&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47198&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47198&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47198&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47198&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47198&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47198&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47198&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47198&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47198&r=mysqlcfg
#47197 [NEW]: PHP ignores configuration option --with-mysql-sock
From: coreync at gmail dot com Operating system: Centos 5.2 PHP version: 5.2.8 PHP Bug Type: *Configuration Issues Bug description: PHP ignores configuration option --with-mysql-sock Description: As seen in this phpinfo file: http://friendcodes.com/info.php When using --with-mysql-sock=/var/lib/mysql/mysql.sock as a configure tag, php still uses the server's mysql default socket location (scroll down to mysql section in the phpinfo). Expected result: I expected php to pass the socket location entered during configure to the mysql client. Actual result: -- Did not pass the socket location to the mysql client. Resolved by creating a symbolic link. -- Edit bug report at http://bugs.php.net/?id=47197&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47197&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47197&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47197&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47197&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47197&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47197&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47197&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47197&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47197&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47197&r=support Expected behavior: http://bugs.php.net/fix.php?id=47197&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47197&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47197&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47197&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47197&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47197&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47197&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47197&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47197&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47197&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47197&r=mysqlcfg
#46680 [Asn->Csd]: Files created in wrong directory (include path vs current working directory)
ID: 46680
Updated by: z...@php.net
Reported By: a...@php.net
-Status: Assigned
+Status: Closed
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5.3CVS-2008-11-26 (snap)
Assigned To: zoe
New Comment:
Fixed tests
Previous Comments:
[2009-01-19 16:20:08] z...@php.net
Fixed ext/standard/tests/file/file_put_contents_variation5.phpt
Adding:
filetype_variation2.phpt
[2009-01-03 15:52:03] z...@php.net
If the behaviour is correct in 5.3 the tests need to be fixed. I'm have
re-opened and assigned to myself to fix.
[2008-12-10 12:19:53] dmi...@php.net
I suppose the behavior in 5.3 is proper and the tests are wrong.
In 5.3 Both fopen() and file_put_contents() first look for file in
include path and in case of failure create new file in current working
directory. May be it should be changed to create it in first element of
include_path, but what should php to do if such directory doesn't
exist... Creation file in "script" directory (as 5.2 does, and what
tests expect) makes no sense.
BTW I don't see a lot of sense in usage of include_path with "create"
functions at all.
[2008-12-09 19:37:29] cel...@php.net
first of all, the change from PHP 5.2 is the addition of
php_resolve_path, which is Dmitry's work. Second of all, most of the
tests are checking for *broken* behavior which is fixed in PHP 5.3.
file_put_contents('blah', 'whatever', FILE_USE_INCLUDE_PATH);
should not arbitrarily create the "blah" file in the first element of
the include_path. file_get_contents('blah', true) does not work this
way, it scans include_path for the file, and if not found, it tries as a
fallback to search in the current directory, and only then does it fail.
This is correct behavior - the file should be created in the current
directory if it does not already exist in the include_path. The
addition of the fallback was added in PHP 5.3, it seems.
The fopen tests also assume that fopen() with include_path parameter
for read will not check the current directory.
So we have a larger dilemma - the default include_path has the current
directory as the first element, and thus the functions that use
include_path for writing were acting as if they were doing the right
thing, when in fact they were making an arbitrary assumption about where
to put things.
None of this behavior is documented, so it is questionable what is the
right way to do things.
In other words, Jani is wrong to imply that anything I did caused the
problem, and should probably apologize, but I won't hold my breath.
I'm assigning to Dmitry under the assumption he will want to do the
ultimate commit, but will raise this on internals@
[2008-11-26 10:15:48] a...@php.net
Description:
The following tests were ported from 5.2.X and do not work as
expected on 5.3. The tests all create a test file and expect it to be
created in an include directory. Instead it looks like the file is
being created elsewhere This particularly affects file_put_contents()
with the FILE_USE_INCLUDE_PATH flag set, and also fopen(...).
Reproduce code:
---
See the tests now checked into CVS:
ext/standard/tests/file/file_put_contents_variation4.phpt
ext/standard/tests/file/file_put_contents_variation5.phpt
ext/standard/tests/file/file_put_contents_variation6.phpt
ext/standard/tests/file/fopen_variation5.phpt
ext/standard/tests/file/fopen_variation7.phpt
ext/standard/tests/file/fopen_variation8.phpt
ext/standard/tests/file/fopen_variation9.phpt
ext/standard/tests/file/fopen_variation12.phpt
ext/standard/tests/file/fopen_variation16.phpt
ext/standard/tests/file/fopen_variation17.phpt
Expected result:
See expected output in the PHPTs.
Actual result:
--
See the test results from running the PHPTs.
--
Edit this bug report at http://bugs.php.net/?id=46680&edit=1
#47195 [Opn->WFx]: Class for easier sending HTTP Headers
ID: 47195
Updated by: paj...@php.net
Reported By: csnaitsirch at web dot de
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: Debian/Linux
PHP Version: 5.2.8
New Comment:
Take a look at http://pecl.php.net/http
Previous Comments:
[2009-01-23 09:04:20] csnaitsirch at web dot de
Description:
In my opinion it is difficult to send special HTTP headers.
If you create a File programaticly and want to send it to the user, you
have to use something like:
So I have written some classes to make it easier.
The same result of the upper example will be reached with the
following:
ContentType()->ApplicationOctetStream();
$h->ContentDisposition()->Attachment()->Filename("file.csv");
$h->ContentLength($csv);
?>
If you think it would be a helpful class mail me.
--
Edit this bug report at http://bugs.php.net/?id=47195&edit=1
#47195 [NEW]: Class for easier sending HTTP Headers
From: csnaitsirch at web dot de
Operating system: Debian/Linux
PHP version: 5.2.8
PHP Bug Type: Feature/Change Request
Bug description: Class for easier sending HTTP Headers
Description:
In my opinion it is difficult to send special HTTP headers.
If you create a File programaticly and want to send it to the user, you
have to use something like:
So I have written some classes to make it easier.
The same result of the upper example will be reached with the following:
ContentType()->ApplicationOctetStream();
$h->ContentDisposition()->Attachment()->Filename("file.csv");
$h->ContentLength($csv);
?>
If you think it would be a helpful class mail me.
--
Edit bug report at http://bugs.php.net/?id=47195&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47195&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47195&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47195&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47195&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47195&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47195&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47195&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47195&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47195&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47195&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47195&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47195&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47195&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47195&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47195&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47195&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47195&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47195&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47195&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47195&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47195&r=mysqlcfg
#47194 [Opn->Asn]: documentation workflow change
ID: 47194 Updated by: cwei...@php.net Reported By: samm...@php.net -Status: Open +Status: Assigned Bug Type:Feature/Change Request PHP Version: 5.2.8 -Assigned To: +Assigned To: cweiske Previous Comments: [2009-01-22 21:31:39] samm...@php.net Description: Translations can among others have the status "working". A file can have the status "working" for one of two reasons: 1. The file is outdated and needs revision. 2. A translator is currently working on this file, but the work is not yet completed. In any case this file is clearly not ready to be published and should not be included in a full build for the manual in this language. Omitting files with status "working" from the build will also considerably speed up the build process. To manage these files and coordinate translation efforts, a list of files with status "working" needs to be created before the manual build. Also, during this preprocessing phase files that are outdated need to be identified and set to status working. A file is outdated when 1. its version number is different from the version number of its corrosponding en version number AND 2. the file has not been touched for more than days. will be defined for each language in a separate file and is dependent on the policy of the translation team for that language. The following changes to the build process are requested: 1. Check for files that are outdated and set the status flag for outdated files to "working". 2. Generate a list of files (ascii, one full pathname per line) that have the status "working". 3. Change the build to omit files with status "working", maybe using the file from step 2 as an exclude list. -- Edit this bug report at http://bugs.php.net/?id=47194&edit=1
