[PHP-BUG] Bug #54726 [NEW]: partial open_basedir path no longer works
From:
Operating system: CentOS release 5.4 (Final)
PHP version: 5.3.6
Package: Safe Mode/open_basedir
Bug Type: Bug
Bug description:partial open_basedir path no longer works
Description:
Our VirtualHost points to a symlink which links to the document_root of the
current application version.
Example directory list;
l /var/www/html/application -> /var/www/html/application-v1.2.3
d /var/www/html/application-v1.2.2
d /var/www/html/application-v1.2.3
Before v5.3 (5.2.4 I think) using the entire symlink path as open_basedir
value
would sitll trigger
open_basedir error's. We worked around this problem by using the partial
suffix
'/var/www/html/app'.
This behaviour was fixed when we upgraded to v5.3.2 were the entire symlink
path
would work as well, but we
did not bother to update all our vhost's as both methods now worked.
But now we have upgraded to v5.3.6 the partial paths no longer work.
Warning: require_once() [function.require-once]: open_basedir restriction
in
effect.
File(/var/www/html/application-v1.2.3/bootstrap.php) is not within the
allowed
path(s): (.:/var/www/html/app)
This behaviour seems to be broken since r305698 where the open_basedir is
always
appended with a directory
separator;
--- php/php-src/trunk/main/fopen_wrappers.c 2010/11/23 21:49:18 305697
+++ php/php-src/trunk/main/fopen_wrappers.c 2010/11/23 22:14:54 305698
@@ -233,6 +233,9 @@
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
+ } else {
+ resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
+ resolved_basedir[resolved_basedir_len] = '\0';
}
resolved_name_len = strlen(resolved_name);
I don't think this change was intended because it is not listed in the
changelog, and breaks backward
compatibility in a minor release.
--
Edit bug report at http://bugs.php.net/bug.php?id=54726&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54726&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54726&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54726&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54726&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54726&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54726&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54726&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54726&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54726&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54726&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54726&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54726&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54726&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54726&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54726&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54726&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54726&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54726&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54726&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54726&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54726&r=mysqlcfg
Bug #54444 [Com]: Multiple Queries on a single conenction
Edit report at http://bugs.php.net/bug.php?id=5&edit=1
ID: 5
Comment by: peter dot colclough at toolstation dot com
Reported by:peter dot colclough at toolstation dot com
Summary:Multiple Queries on a single conenction
Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: Ubuntu 10 64 bit
PHP Version:5.3SVN-2011-04-01 (SVN)
Block user comment: N
Private report: N
New Comment:
Johannes,
I accept what you, and Ulf, are saying, however do you think it
right that the language shouold dictate what the application developer
can do? While it would be really dumb to have 6 x 10 gig results stored
on the server, it may be a necessity, and memory is not a main issue
these days. Its up to the app developer how they store the data, and
where it is stored mid query.
We are processing, on average, 1000 queries a second over any 24 hr
period. Some of those have complex joins, which in turn cause table
locks. By using multiple prepared statements, we can get around that
issue, and speed up total throughput.
Will let you know when the driver is available in alpha... so you can
pass comments, if you are interested.
Previous Comments:
[2011-05-11 11:12:25] johan...@php.net
The server won't process a second query unless all data from the
previous has been fetched. As Ulf said you can buffer the result set
locally so you can send the next query. We don't do this intentionally
by default as loading result sets in memory can be very hard when they
are large.
[2011-05-10 12:01:00] peter dot colclough at toolstation dot com
True... but it doesn't do this ($conn is a connection) ... and don't
copy this code.. its not good.. but gets the point across:
$basesql = 'SELECT SQL_NO_CACHE id from table1 ';
$baseqry = bmysqli_query($basesql, $conn);
$qry = bmysqli_query('Select SQL_NO_CACHE * from table2 where id2 = ?
',$conn);
$qry1 = bmysqli_query('Select SQL_NO_CACHE * from table3 where id3 = ?
',$conn);
$qry2 = bmysqli_query('Select SQL_NO_CACHE * from table4 where id4 = ?
',$conn);
while(TRUE){
$nBaseRes = bmysqli_fetch($baseqry);
if(empty($nBaseRes)){
break;
}
$aId = array(0 =>$nBaseRes['id']);
// The first bound query
bmysqli_execute($qry, $aId);
$nRes = bmysqli_fetch($qry);
$aVals = array(0=>$nRes['id2']);
bmysqli_execute($qry1, $aVals);
while(TRUE){// careful Peter
$nRes1 = bmysqli_fetch($qry1);
if(empty($nRes1)){
break;
}
$aItems = array(0 => $nRes1['id3']);
bmysqli_execute($qry2, $aItems);
while(TRUE){// careful Peter
$nRes2 = bmysqli_fetch($qry2);
if(empty($nRes2)){
break;
}
}
}
[2011-05-09 17:00:40] u...@php.net
Hmm, you can prepare as many statements as you want per connection. But
once you have executed a statement on a connection you must fetch its
results before you can execute another statement. The result set
"blocks" the line.
You can, of course, do an implicit fetch on the C level upon execute but
that's the exact opposite of the default fetch method (unbuffered) used
for prepared statements by MySQL.
Its a one-liner to do that fetch in user land. No need for changes on
the C level.
$mysqli = new mysqli("localhost", "root", "root", "test");
$stmt1 = $mysqli->prepare("SELECT 1 AS _one FROM DUAL");
$stmt2 = $mysqli->prepare("SELECT 2 AS _two FROM DUAL");
/* execute */
if (!$stmt1->execute())
printf("[001] [%d] %s\n", $stmt1->errno, $stmt1->error);
/* clear line by fetching result set */
$res1 = $stmt1->get_result();
/* execute */
if (!$stmt2->execute())
printf("[002] [%d] %s\n", $stmt2->errno, $stmt2->error);
/* clear line by fetching result set */
$res2 = $stmt2->get_result();
/* fetching second first */
while ($row = $res2->fetch_assoc())
var_dump($row);
$res2->free();
while ($row = $res1->fetch_assoc())
var_dump($row);
$res1->free();
[2011-05-09 16:35:37] peter dot colclough at toolstation dot com
Thanks for teh feedback. I was also getting that error, just wanted to
make sure it wasn't 'me'... but actually expected behaviour.
Am now devbeloping my own, that allows multiple statements per
connection, as well as multiple 'prepare' statements. This will be open
sourced when ready.
The current mysqli interface should have been able to do this, but it
was obviously decided not
Bug #54444 [Bgs]: Multiple Queries on a single conenction
Edit report at http://bugs.php.net/bug.php?id=5&edit=1
ID: 5
Updated by: johan...@php.net
Reported by:peter dot colclough at toolstation dot com
Summary:Multiple Queries on a single conenction
Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: Ubuntu 10 64 bit
PHP Version:5.3SVN-2011-04-01 (SVN)
Block user comment: N
Private report: N
New Comment:
You can use mysqli_store_result or mysqli_fetch_all to fetch the result
set into local memory. And in a system with 100 or so PHP processes in
parallel memory is still an issue. You are free to do whatever you want,
there's no limitation. The main thing is that after bad experience with
the mysql_query() behaviour we've changed the default with mysqli for
being unbuffered. (To have this more CS like: The unbuffered approach
let's you write applications with complexity O(n), with buffered the
same thing will be O(2n) )
Previous Comments:
[2011-05-13 09:59:59] peter dot colclough at toolstation dot com
Johannes,
I accept what you, and Ulf, are saying, however do you think it
right that the language shouold dictate what the application developer
can do? While it would be really dumb to have 6 x 10 gig results stored
on the server, it may be a necessity, and memory is not a main issue
these days. Its up to the app developer how they store the data, and
where it is stored mid query.
We are processing, on average, 1000 queries a second over any 24 hr
period. Some of those have complex joins, which in turn cause table
locks. By using multiple prepared statements, we can get around that
issue, and speed up total throughput.
Will let you know when the driver is available in alpha... so you can
pass comments, if you are interested.
[2011-05-11 11:12:25] johan...@php.net
The server won't process a second query unless all data from the
previous has been fetched. As Ulf said you can buffer the result set
locally so you can send the next query. We don't do this intentionally
by default as loading result sets in memory can be very hard when they
are large.
[2011-05-10 12:01:00] peter dot colclough at toolstation dot com
True... but it doesn't do this ($conn is a connection) ... and don't
copy this code.. its not good.. but gets the point across:
$basesql = 'SELECT SQL_NO_CACHE id from table1 ';
$baseqry = bmysqli_query($basesql, $conn);
$qry = bmysqli_query('Select SQL_NO_CACHE * from table2 where id2 = ?
',$conn);
$qry1 = bmysqli_query('Select SQL_NO_CACHE * from table3 where id3 = ?
',$conn);
$qry2 = bmysqli_query('Select SQL_NO_CACHE * from table4 where id4 = ?
',$conn);
while(TRUE){
$nBaseRes = bmysqli_fetch($baseqry);
if(empty($nBaseRes)){
break;
}
$aId = array(0 =>$nBaseRes['id']);
// The first bound query
bmysqli_execute($qry, $aId);
$nRes = bmysqli_fetch($qry);
$aVals = array(0=>$nRes['id2']);
bmysqli_execute($qry1, $aVals);
while(TRUE){// careful Peter
$nRes1 = bmysqli_fetch($qry1);
if(empty($nRes1)){
break;
}
$aItems = array(0 => $nRes1['id3']);
bmysqli_execute($qry2, $aItems);
while(TRUE){// careful Peter
$nRes2 = bmysqli_fetch($qry2);
if(empty($nRes2)){
break;
}
}
}
[2011-05-09 17:00:40] u...@php.net
Hmm, you can prepare as many statements as you want per connection. But
once you have executed a statement on a connection you must fetch its
results before you can execute another statement. The result set
"blocks" the line.
You can, of course, do an implicit fetch on the C level upon execute but
that's the exact opposite of the default fetch method (unbuffered) used
for prepared statements by MySQL.
Its a one-liner to do that fetch in user land. No need for changes on
the C level.
$mysqli = new mysqli("localhost", "root", "root", "test");
$stmt1 = $mysqli->prepare("SELECT 1 AS _one FROM DUAL");
$stmt2 = $mysqli->prepare("SELECT 2 AS _two FROM DUAL");
/* execute */
if (!$stmt1->execute())
printf("[001] [%d] %s\n", $stmt1->errno, $stmt1->error);
/* clear line by fetching result set */
$res1 = $stmt1->get_result();
/* execute */
if (!$stmt2->execute())
printf("[002] [%d] %s\n", $stmt2->errno, $stmt2->error);
/* clear line by fetching result set */
$res2 = $stmt2->get_result();
/* fetching second first */
while ($row = $res2->fetch_assoc())
[PHP-BUG] Bug #54727 [NEW]: ob_flush() before output_reset_rewrite_vars() results in data loss
From: Operating system: * PHP version: trunk-SVN-2011-05-13 (SVN) Package: Output Control Bug Type: Bug Bug description:ob_flush() before output_reset_rewrite_vars() results in data loss Description: The test for http://bugs.php.net/bug.php?id=26862 currently fails and results in the last echo statement (everything after ob_flush() and output_reset_rewrite_vars()) to get lost. A variant of the issue was reintroduced after the output buffering rewrite. This seems to happen because the output is never handled if there is no rewrite variables to process and there is no active buffer with contents. The output chars still needs to returned as handled. The patch also contains a small change in the test to better differentiate the two echo statements. Test script: --- Based on: ext/session/tests/bug26862.phpt link'; ob_flush(); output_reset_rewrite_vars(); echo 'link'; Expected result: linklink Actual result: -- link -- Edit bug report at http://bugs.php.net/bug.php?id=54727&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54727&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54727&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54727&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54727&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54727&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54727&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54727&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54727&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54727&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54727&r=support Expected behavior: http://bugs.php.net/fix.php?id=54727&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54727&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54727&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54727&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54727&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54727&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54727&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54727&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54727&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54727&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54727&r=mysqlcfg
[PHP-BUG] Bug #54729 [NEW]: mail is not sent when the body contains a specific web-link
From: Operating system: sles11, opensuse PHP version: 5.2.17 Package: Scripting Engine problem Bug Type: Bug Bug description:mail is not sent when the body contains a specific web-link Description: mail() does not send an email when the body contains a specific web-link. This happens also with 5.3.3. It seems that mail() does interpret the Link and doesn't send an e-mail if after the ".de" is something appended. Test script: --- http://www.ku-ett.de";); mail( "to...@ku-ett.de", "Bad Link", "http://www.ku-ett.de.ms";); ?> -- Edit bug report at http://bugs.php.net/bug.php?id=54729&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54729&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54729&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54729&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54729&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54729&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54729&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54729&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54729&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54729&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54729&r=support Expected behavior: http://bugs.php.net/fix.php?id=54729&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54729&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54729&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54729&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54729&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54729&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54729&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54729&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54729&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54729&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54729&r=mysqlcfg
[PHP-BUG] Bug #54730 [NEW]: comparison float
From: Operating system: Linux PHP version: 5.3.6 Package: Math related Bug Type: Bug Bug description:comparison float Description: view result Test script: --- Expected result: float(206667) float(206667) Is equal ? true Actual result: -- float(206667) float(206667) Is equal ? false -- Edit bug report at http://bugs.php.net/bug.php?id=54730&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54730&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54730&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54730&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54730&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54730&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54730&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54730&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54730&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54730&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54730&r=support Expected behavior: http://bugs.php.net/fix.php?id=54730&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54730&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54730&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54730&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54730&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54730&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54730&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54730&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54730&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54730&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54730&r=mysqlcfg
[PHP-BUG] Bug #54731 [NEW]: MySQL package failed configure PHP 5.3.6
From:
Operating system: Linux 2.6.32-5-686 i686 GNU/Linu
PHP version: 5.3.6
Package: MySQL related
Bug Type: Bug
Bug description:MySQL package failed configure PHP 5.3.6
Description:
linux:~# mysql --version
mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (i486) using readline
6.1
linux:~# ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-zlib
--enable-wddx --enable-sockets --with-openssl --with-mysql=/usr/bin/
--with-mcrypt --enable-mbstring --enable-bcmath --enable-calendar
--with-curl --enable-exif --enable-ftp --with-gd --with-gettext
...
configure:59659: checking for MySQL support
configure:59703: checking for specified location of the MySQL UNIX socket
configure:59901: checking for mysql_close in -lmysqlclient
configure:59920: gcc -o conftest -I/usr/include -g -O2 -fvisibility=hidden
-L/usr/lib conftest.c -lmysqlclient -lmcrypt -lltdl -lpng -lz -lcurl -lz
-lrt -lm -ldl -lnsl -lxml2 -lssl -lcrypto -lcurl -lxml2 -lssl -lcrypto
1>&5
/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
configure: failed program was:
#line 59909 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_close();
int main() {
mysql_close()
; return 0; }
configure:60143: checking for mysql_error in -lmysqlclient
configure:60162: gcc -o conftest -I/usr/include -g -O2 -fvisibility=hidden
-L/usr/lib -Wl,-rpath,/usr -L/usr conftest.c -lmysqlclient -lz -lmcrypt
-lltdl -lpng -lz -lcurl -lz -lrt -lm -ldl -lnsl -lxml2 -lssl -lcrypto
-lcurl -lxml2 -lssl -lcrypto 1>&5
/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
configure: failed program was:
#line 60151 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_error();
int main() {
mysql_error()
; return 0; }
Test script:
---
linux:~# ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-zlib
--enable-wddx --enable-sockets --with-openssl --with-mysql=/usr/bin/
--with-mcrypt --enable-mbstring --enable-bcmath --enable-calendar
--with-curl --enable-exif --enable-ftp --with-gd --with-gettext
--
Edit bug report at http://bugs.php.net/bug.php?id=54731&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54731&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54731&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54731&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54731&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54731&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54731&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54731&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54731&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54731&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54731&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54731&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54731&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54731&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54731&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54731&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54731&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54731&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54731&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54731&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54731&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54731&r=mysqlcfg
Bug #54731 [Opn->Csd]: MySQL package failed configure PHP 5.3.6
Edit report at http://bugs.php.net/bug.php?id=54731&edit=1
ID: 54731
User updated by:shrimpwagon at yahoo dot com
Reported by:shrimpwagon at yahoo dot com
Summary:MySQL package failed configure PHP 5.3.6
-Status: Open
+Status: Closed
Type: Bug
Package:MySQL related
Operating System: Linux 2.6.32-5-686 i686 GNU/Linu
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
All I had to do was install package libltdl-dev
Previous Comments:
[2011-05-13 21:44:12] shrimpwagon at yahoo dot com
Description:
linux:~# mysql --version
mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (i486) using
readline 6.1
linux:~# ./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-zlib --enable-wddx --enable-sockets --with-openssl
--with-mysql=/usr/bin/ --with-mcrypt --enable-mbstring --enable-bcmath
--enable-calendar --with-curl --enable-exif --enable-ftp --with-gd
--with-gettext
...
configure:59659: checking for MySQL support
configure:59703: checking for specified location of the MySQL UNIX
socket
configure:59901: checking for mysql_close in -lmysqlclient
configure:59920: gcc -o conftest -I/usr/include -g -O2
-fvisibility=hidden -L/usr/lib conftest.c -lmysqlclient -lmcrypt
-lltdl -lpng -lz -lcurl -lz -lrt -lm -ldl -lnsl -lxml2 -lssl -lcrypto
-lcurl -lxml2 -lssl -lcrypto 1>&5
/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
configure: failed program was:
#line 59909 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_close();
int main() {
mysql_close()
; return 0; }
configure:60143: checking for mysql_error in -lmysqlclient
configure:60162: gcc -o conftest -I/usr/include -g -O2
-fvisibility=hidden -L/usr/lib -Wl,-rpath,/usr -L/usr conftest.c
-lmysqlclient -lz -lmcrypt -lltdl -lpng -lz -lcurl -lz -lrt -lm -ldl
-lnsl -lxml2 -lssl -lcrypto -lcurl -lxml2 -lssl -lcrypto 1>&5
/usr/bin/ld: cannot find -lltdl
collect2: ld returned 1 exit status
configure: failed program was:
#line 60151 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_error();
int main() {
mysql_error()
; return 0; }
Test script:
---
linux:~# ./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-zlib --enable-wddx --enable-sockets --with-openssl
--with-mysql=/usr/bin/ --with-mcrypt --enable-mbstring --enable-bcmath
--enable-calendar --with-curl --enable-exif --enable-ftp --with-gd
--with-gettext
--
Edit this bug report at http://bugs.php.net/bug.php?id=54731&edit=1
[PHP-BUG] Bug #54732 [NEW]: the string replacement of CRLF does not work consistently
From:
Operating system: All
PHP version: Irrelevant
Package: *General Issues
Bug Type: Bug
Bug description:the string replacement of CRLF does not work consistently
Description:
No matter how many ways CRLF (\r\n) has been tried to be replaced in a PHP
script by , it does not produce a consistent result.
This happens especially when trying to parse returned whois information.
The $info in the following script will work with some parsing of the whois
info with a string replacement of a CRLF (\r\n) on one domain (registrar)
and yet on a different domain it will not work at all.
I have looked at the differing outputs (depending on domain name) with a
HEX editor and I know for a fact that there is a replacement problem with
CRLF and php. I have tried A LOT of various scripts from people having the
same problem, with no further success. The replacement of \r\n should be
straight forward as in other languages but it is not in php. Perhaps a
special function should be made for the task of replacemet of CRLF with
another character.
Have a look at the code below. Try different domain names and notice how
the CRLF is parsed (with your own code to parse $info) on some domain
information it will work and yet other domains it will not parse the CRLF
(HEX-ODOA)!
This is an ongoing problem for other people as well.
Test script:
---
query('example.com');
echo($info);
?>
Expected result:
Please fix this string replacement problem _PLEASE.
--
Edit bug report at http://bugs.php.net/bug.php?id=54732&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54732&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54732&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54732&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54732&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54732&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54732&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54732&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54732&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54732&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54732&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54732&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54732&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54732&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54732&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54732&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54732&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54732&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54732&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54732&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54732&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54732&r=mysqlcfg
Bug #34972 [Com]: STDIN won't allow nonblocking.
Edit report at http://bugs.php.net/bug.php?id=34972&edit=1
ID: 34972
Comment by: dewi at dewimorgan dot com
Reported by:VJTD3 at VJTD3 dot com
Summary:STDIN won't allow nonblocking.
Status: Assigned
Type: Bug
Package:Streams related
Operating System: win32 only
PHP Version:5.2CVS-2008-07-15
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
As I understand it (and some or all of this post may be wrong: please
correct!), this is a platform limitation, since stuff like Windows'
SetCommTimeouts() doesn't work for the stdin handle. I believe that this
is because of the way pipes are handled under Windows, which makes them
line-based rather than character-based.
Any true "fix" (rather than just editing the docs) is a Hard Problem,
since PHP has no control over Windows pipes.
The windows PHP port could internally do something nasty like:
if (ftell(STDIN) === 0) {
// STDIN is the real STDIN, from a file or piped command.
}
else {
// STDIN is a faked STDIN, built from keypresses.
}
This would fix the issue for those wanting interactive input, but the
issue would still show up for pipes that aren't line separated:
ReplayKeyboardInput.exe | myScript.php
And even ignoring pipes, faking STDIN isn't trivial, either, but would
probably involve a call to PeekConsoleInput().
I'm pretty sure if someone has some magic way for the receiving end of a
pipe to make the pipe behave in a character-based way under Windows,
then they'd happily implement it.
I'm considerably less convinced that they'd be willing to muddy PHP with
a STDIN kludge that wouldn't work in some cases.
The NEED most people are expressing here is the need for interactive
console input, via nonblocking keyboard reads, rather than the need for
character-based pipes.
So, a "more correct" option would likely to be getting the ncurses
extension working under Windows - the one platform that really needs it,
and doesn't have it :) The public domain pdcurses.sourceforge.net may be
useful here.
Workarounds:
As a workaround for PHP programmers on windows in the meantime, an
external program that reads a single keypress can be used.
For people who don't mind blocking, this should work:
$KeyPressed = `perl -e "use Term::ReadKey;ReadMode 'cbreak';
print(ReadKey(0)); ReadMode 'normal';"`
To get nonblocking behaviour, where you can just read pending
keystrokes, you'd need to launch that in a separate process, give it
focus, and get it to send the characters to PHP whenever it read a
character, and get your php file to poll the same file/socket for
changes.
If you don't have perl installed, a similar external program could
likely be written in PowerShell, running as root and using
$host.ui.rawui.KeyAvailable a WMI listener - but that's a crazy hoop to
have to leap through.
Unless you have a really pressing need to write your app in PHP, then,
odds are, it's easier to just write your script in a language which has
functions for reading the keyboard directly (Perl, PowerShell, Python,
AutoHotKey...). Or write a php readkey extension that launches a
keyboard monitor in a separate thread or something, with start, stop,
and flush functions for that key buffer.
Previous Comments:
[2011-01-01 10:48:41] paj...@php.net
@support at aculane dot com
what makes you think that anything has been done about this feature
request?
[2011-01-01 10:33:12] support at aculane dot com
PHP 5.3 (5.3.4) VC9 x86 Thread Safe (2010-Dec-09 23:14:27) windows
7(64bit os)
Exact same problem.
[2010-12-24 10:14:21] lgynove at 163 dot com
5 years after the bug should not be there.
[2010-10-02 17:25:14] axellc dot perso at gmail dot com
Have same problem with 5.3.3 on windows (7)
I still can't use my php5-cli shell applications on Windows :s
[2010-08-31 13:13:26] me at ben-xo dot com
Experiencing this issue on Win 32 with PHP 5.3.2.
stream_set_blocking(STDIN, 0)
('correctly') returns false and does not allow non-blocking. Also
experiencing
issues using stream_select() on STDIN. STDIN always comes back as ready
for
reading, but reading from it blocks.
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/bug.php?id=34972
--
Edit this bug report at http://bugs.php.net/bug.php?id=34972&edit=1
Bug #54730 [Opn->Bgs]: comparison float
Edit report at http://bugs.php.net/bug.php?id=54730&edit=1
ID: 54730
Updated by: ras...@php.net
Reported by:dancho at hahpss dot com
Summary:comparison float
-Status: Open
+Status: Bogus
Type: Bug
Package:Math related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
Try adding ini_set('precision',32); to the top of your test script and
it should
be clear why these are not equal.
Previous Comments:
[2011-05-13 20:01:09] dancho at hahpss dot com
Description:
view result
Test script:
---
Expected result:
float(206667)
float(206667)
Is equal ? true
Actual result:
--
float(206667)
float(206667)
Is equal ? false
--
Edit this bug report at http://bugs.php.net/bug.php?id=54730&edit=1
[PHP-BUG] Bug #54733 [NEW]: PDOStatement->execute using libmysql segfaults
From:
Operating system: Debian 5.0.8 (lenny)
PHP version: 5.3.6
Package: PDO related
Bug Type: Bug
Bug description:PDOStatement->execute using libmysql segfaults
Description:
When using pdo_mysql compiled against libmysql, calling
PDOStatement->execute in
the given context results in a segmentation fault.
Strangely, it's only when both columns `a` and `c` are selected that the
segfault occurs, not when they are fetched independently.
~$ uname -a
Linux karin 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686
GNU/Linux
~$ ldd /usr/local/lib/php/extensions/no-debug-zts-20090626/pdo_mysql.so
linux-gate.so.1 => (0xb7712000)
libmysqlclient_r.so.16 =>
/usr/local/mysql/lib/mysql/libmysqlclient_r.so.16 (0xb7696000)
libz.so.1 => /usr/lib/libz.so.1 (0xb767b000)
libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7648000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb762f000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7609000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb75f)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7495000)
/lib/ld-linux.so.2 (0xb7713000)
Please let me know if you require my `php --info`.
Test script:
---
exec("DROP TABLE IF EXISTS `system`");
$connection->exec("
CREATE TABLE `t` (
`a` varchar(255),
`b` varchar(255),
`c` varchar(255)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
");
$statement = $connection->prepare("SELECT a, c FROM t WHERE b = :b");
// segfault
$statement->execute(array(':b' => 'blah'));
?>
Expected result:
Test script should return 0.
Actual result:
--
~$ gdb --args php pdo_mysql_segfault.php
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /usr/local/bin/php pdo_mysql_segfault.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb718d6d0 (LWP 4010)]
[New Thread 0xb6561b90 (LWP 4013)]
[Thread 0xb6561b90 (LWP 4013) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb718d6d0 (LWP 4010)]
0xb72244f3 in strlen () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0 0xb72244f3 in strlen () from /lib/i686/cmov/libc.so.6
#1 0xb6572764 in pdo_mysql_stmt_describe (stmt=0x996c83c, colno=0,
tsrm_ls=0x97b4050)
at /usr/local/src/php-5.3.6/ext/pdo_mysql/mysql_statement.c:700
#2 0xb6583032 in pdo_stmt_describe_columns (stmt=0x996c83c,
tsrm_ls=0x97b4050)
at /usr/local/src/php-5.3.6/ext/pdo/pdo_stmt.c:209
#3 0xb65856fe in zim_PDOStatement_execute (ht=1, return_value=0x996cad0,
return_value_ptr=0x0, this_ptr=0x996b804, return_value_used=0,
tsrm_ls=0x97b4050) at /usr/local/src/php-5.3.6/ext/pdo/pdo_stmt.c:519
#4 0x08348758 in zend_do_fcall_common_helper_SPEC (execute_data=0x999e798,
tsrm_ls=0x97b4050) at
/usr/local/src/php-5.3.6/Zend/zend_vm_execute.h:316
#5 0x08344089 in execute (op_array=0x996bcac, tsrm_ls=0x97b4050)
at /usr/local/src/php-5.3.6/Zend/zend_vm_execute.h:107
#6 0x082f28c6 in zend_execute_scripts (type=8, tsrm_ls=0x97b4050,
retval=0x0,
file_count=3) at /usr/local/src/php-5.3.6/Zend/zend.c:1194
#7 0x08292890 in php_execute_script (primary_file=0xbfa7a708,
tsrm_ls=0x97b4050) at /usr/local/src/php-5.3.6/main/main.c:2268
#8 0x08387c1a in main (argc=2, argv=0xbfa7a864)
at /usr/local/src/php-5.3.6/sapi/cli/php_cli.c:1193
--
Edit bug report at http://bugs.php.net/bug.php?id=54733&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54733&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54733&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54733&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54733&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54733&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54733&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54733&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54733&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54733&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54733&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54733&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54733&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=5
Bug #54733 [Opn]: PDOStatement->execute using libmysql segfaults
Edit report at http://bugs.php.net/bug.php?id=54733&edit=1
ID: 54733
User updated by:dan at mutual dot io
Reported by:dan at mutual dot io
Summary:PDOStatement->execute using libmysql segfaults
Status: Open
Type: Bug
Package:PDO related
Operating System: Debian 5.0.8 (lenny)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, I forgot to mention that the segmentation fault does not occur
when PHP is
configured with `--with-pdo-mysql=mysqlnd`.
And my libmysql is 5.1.55, compiled from source.
Thanks!
Previous Comments:
[2011-05-14 04:09:59] dan at mutual dot io
Description:
When using pdo_mysql compiled against libmysql, calling
PDOStatement->execute in
the given context results in a segmentation fault.
Strangely, it's only when both columns `a` and `c` are selected that the
segfault occurs, not when they are fetched independently.
~$ uname -a
Linux karin 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686
GNU/Linux
~$ ldd /usr/local/lib/php/extensions/no-debug-zts-20090626/pdo_mysql.so
linux-gate.so.1 => (0xb7712000)
libmysqlclient_r.so.16 =>
/usr/local/mysql/lib/mysql/libmysqlclient_r.so.16 (0xb7696000)
libz.so.1 => /usr/lib/libz.so.1 (0xb767b000)
libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb7648000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb762f000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7609000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb75f)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7495000)
/lib/ld-linux.so.2 (0xb7713000)
Please let me know if you require my `php --info`.
Test script:
---
exec("DROP TABLE IF EXISTS `system`");
$connection->exec("
CREATE TABLE `t` (
`a` varchar(255),
`b` varchar(255),
`c` varchar(255)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
");
$statement = $connection->prepare("SELECT a, c FROM t WHERE b = :b");
// segfault
$statement->execute(array(':b' => 'blah'));
?>
Expected result:
Test script should return 0.
Actual result:
--
~$ gdb --args php pdo_mysql_segfault.php
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /usr/local/bin/php pdo_mysql_segfault.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb718d6d0 (LWP 4010)]
[New Thread 0xb6561b90 (LWP 4013)]
[Thread 0xb6561b90 (LWP 4013) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb718d6d0 (LWP 4010)]
0xb72244f3 in strlen () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0 0xb72244f3 in strlen () from /lib/i686/cmov/libc.so.6
#1 0xb6572764 in pdo_mysql_stmt_describe (stmt=0x996c83c, colno=0,
tsrm_ls=0x97b4050)
at /usr/local/src/php-5.3.6/ext/pdo_mysql/mysql_statement.c:700
#2 0xb6583032 in pdo_stmt_describe_columns (stmt=0x996c83c,
tsrm_ls=0x97b4050)
at /usr/local/src/php-5.3.6/ext/pdo/pdo_stmt.c:209
#3 0xb65856fe in zim_PDOStatement_execute (ht=1,
return_value=0x996cad0,
return_value_ptr=0x0, this_ptr=0x996b804, return_value_used=0,
tsrm_ls=0x97b4050) at
/usr/local/src/php-5.3.6/ext/pdo/pdo_stmt.c:519
#4 0x08348758 in zend_do_fcall_common_helper_SPEC
(execute_data=0x999e798,
tsrm_ls=0x97b4050) at
/usr/local/src/php-5.3.6/Zend/zend_vm_execute.h:316
#5 0x08344089 in execute (op_array=0x996bcac, tsrm_ls=0x97b4050)
at /usr/local/src/php-5.3.6/Zend/zend_vm_execute.h:107
#6 0x082f28c6 in zend_execute_scripts (type=8, tsrm_ls=0x97b4050,
retval=0x0,
file_count=3) at /usr/local/src/php-5.3.6/Zend/zend.c:1194
#7 0x08292890 in php_execute_script (primary_file=0xbfa7a708,
tsrm_ls=0x97b4050) at /usr/local/src/php-5.3.6/main/main.c:2268
#8 0x08387c1a in main (argc=2, argv=0xbfa7a864)
at /usr/local/src/php-5.3.6/sapi/cli/php_cli.c:1193
--
Edit this bug report at http://bugs.php.net/bug.php?id=54733&edit=1
[PHP-BUG] Req #54734 [NEW]: unpack() forces use of associative arrays
From:
Operating system: *
PHP version: 5.3.6
Package: Strings related
Bug Type: Feature/Change Request
Bug description:unpack() forces use of associative arrays
Description:
The unpack() function returns only associative arrays. In some situations
it's advantageous to work with an indexed array instead. For example, this
code, parsing a fictional network packet format:
$packet = "\x01\x05\x05\x01\x05\x05\x01";
$values = unpack("Cpadding/nvalue1/Cpadding/nvalue2/Cpadding", $packet);
might be more clear when written this way:
list(, $value1, , $value2, ) = unpack("CnCnC", $packet);
Implementing a fully compatible workaround in userland is at least mildly
annoying (as well as slow), and it's pretty simple to add to the engine.
--
Edit bug report at http://bugs.php.net/bug.php?id=54734&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54734&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54734&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54734&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54734&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54734&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54734&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54734&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54734&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54734&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54734&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54734&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54734&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54734&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54734&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54734&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54734&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54734&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54734&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54734&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54734&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54734&r=mysqlcfg
Req #54734 [Opn->Fbk]: unpack() forces use of associative arrays
Edit report at http://bugs.php.net/bug.php?id=54734&edit=1
ID: 54734
Updated by: ras...@php.net
Reported by:gwy...@php.net
Summary:unpack() forces use of associative arrays
-Status: Open
+Status: Feedback
Type: Feature/Change Request
Package:Strings related
Operating System: *
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
The userland workaround is rather trivial though, isn't it?
list(, $value1, $value2) = array_values(unpack("CnCnC", $packet));
array_values() is quick, but I guess your performance worry is the
needless
creation of the associative array in the first place?
Previous Comments:
[2011-05-14 06:41:56] gwy...@php.net
Description:
The unpack() function returns only associative arrays. In some
situations it's advantageous to work with an indexed array instead. For
example, this code, parsing a fictional network packet format:
$packet = "\x01\x05\x05\x01\x05\x05\x01";
$values = unpack("Cpadding/nvalue1/Cpadding/nvalue2/Cpadding",
$packet);
might be more clear when written this way:
list(, $value1, , $value2, ) = unpack("CnCnC", $packet);
Implementing a fully compatible workaround in userland is at least
mildly annoying (as well as slow), and it's pretty simple to add to the
engine.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54734&edit=1
Req #54734 [Fbk->Opn]: unpack() forces use of associative arrays
Edit report at http://bugs.php.net/bug.php?id=54734&edit=1
ID: 54734
Updated by: gwy...@php.net
Reported by:gwy...@php.net
Summary:unpack() forces use of associative arrays
-Status: Feedback
+Status: Open
Type: Feature/Change Request
Package:Strings related
Operating System: *
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I was under the impression that it's not safe to depend on the order of
values in an associative array, i.e., that array_values(array("a" =>
"b", "c" => "d")) is free to return array("d", "b") if it likes. Is that
untrue in the current engine?
And yeah, performance is some question. Especially since I am using
unpack for network packets, and the faster the better, though I haven't
done any kind of benchmark to see if this is a bottleneck at all.
Previous Comments:
[2011-05-14 06:59:05] ras...@php.net
The userland workaround is rather trivial though, isn't it?
list(, $value1, $value2) = array_values(unpack("CnCnC", $packet));
array_values() is quick, but I guess your performance worry is the
needless
creation of the associative array in the first place?
[2011-05-14 06:41:56] gwy...@php.net
Description:
The unpack() function returns only associative arrays. In some
situations it's advantageous to work with an indexed array instead. For
example, this code, parsing a fictional network packet format:
$packet = "\x01\x05\x05\x01\x05\x05\x01";
$values = unpack("Cpadding/nvalue1/Cpadding/nvalue2/Cpadding",
$packet);
might be more clear when written this way:
list(, $value1, , $value2, ) = unpack("CnCnC", $packet);
Implementing a fully compatible workaround in userland is at least
mildly annoying (as well as slow), and it's pretty simple to add to the
engine.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54734&edit=1
Req #54734 [Opn]: unpack() forces use of associative arrays
Edit report at http://bugs.php.net/bug.php?id=54734&edit=1
ID: 54734
Updated by: ras...@php.net
Reported by:gwy...@php.net
Summary:unpack() forces use of associative arrays
Status: Open
Type: Feature/Change Request
Package:Strings related
Operating System: *
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
That has never been true in any PHP version. Right from day one PHP
arrays have
been ordered and you have always been able to rely on that order.
Previous Comments:
[2011-05-14 07:08:04] gwy...@php.net
I was under the impression that it's not safe to depend on the order of
values in an associative array, i.e., that array_values(array("a" =>
"b", "c" => "d")) is free to return array("d", "b") if it likes. Is that
untrue in the current engine?
And yeah, performance is some question. Especially since I am using
unpack for network packets, and the faster the better, though I haven't
done any kind of benchmark to see if this is a bottleneck at all.
[2011-05-14 06:59:05] ras...@php.net
The userland workaround is rather trivial though, isn't it?
list(, $value1, $value2) = array_values(unpack("CnCnC", $packet));
array_values() is quick, but I guess your performance worry is the
needless
creation of the associative array in the first place?
[2011-05-14 06:41:56] gwy...@php.net
Description:
The unpack() function returns only associative arrays. In some
situations it's advantageous to work with an indexed array instead. For
example, this code, parsing a fictional network packet format:
$packet = "\x01\x05\x05\x01\x05\x05\x01";
$values = unpack("Cpadding/nvalue1/Cpadding/nvalue2/Cpadding",
$packet);
might be more clear when written this way:
list(, $value1, , $value2, ) = unpack("CnCnC", $packet);
Implementing a fully compatible workaround in userland is at least
mildly annoying (as well as slow), and it's pretty simple to add to the
engine.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54734&edit=1
Req #54734 [Opn]: unpack() forces use of associative arrays
Edit report at http://bugs.php.net/bug.php?id=54734&edit=1
ID: 54734
Updated by: gwy...@php.net
Reported by:gwy...@php.net
Summary:unpack() forces use of associative arrays
Status: Open
Type: Feature/Change Request
Package:Strings related
Operating System: *
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I stand corrected!
That having been said, it's still a bit annoying to have to write the
array_values() every time, and it does feel a bit wasteful to create an
associative array, then create array from just its values, just to
extract it into what's essentially another hash table (the symbol table)
again. A comment in ext/standard/pack.c suggests the original author of
the function rejected the ordered-array approach because it was
error-prone, which now seems a little odd to me given your explanation.
Previous Comments:
[2011-05-14 07:17:00] ras...@php.net
That has never been true in any PHP version. Right from day one PHP
arrays have
been ordered and you have always been able to rely on that order.
[2011-05-14 07:08:04] gwy...@php.net
I was under the impression that it's not safe to depend on the order of
values in an associative array, i.e., that array_values(array("a" =>
"b", "c" => "d")) is free to return array("d", "b") if it likes. Is that
untrue in the current engine?
And yeah, performance is some question. Especially since I am using
unpack for network packets, and the faster the better, though I haven't
done any kind of benchmark to see if this is a bottleneck at all.
[2011-05-14 06:59:05] ras...@php.net
The userland workaround is rather trivial though, isn't it?
list(, $value1, $value2) = array_values(unpack("CnCnC", $packet));
array_values() is quick, but I guess your performance worry is the
needless
creation of the associative array in the first place?
[2011-05-14 06:41:56] gwy...@php.net
Description:
The unpack() function returns only associative arrays. In some
situations it's advantageous to work with an indexed array instead. For
example, this code, parsing a fictional network packet format:
$packet = "\x01\x05\x05\x01\x05\x05\x01";
$values = unpack("Cpadding/nvalue1/Cpadding/nvalue2/Cpadding",
$packet);
might be more clear when written this way:
list(, $value1, , $value2, ) = unpack("CnCnC", $packet);
Implementing a fully compatible workaround in userland is at least
mildly annoying (as well as slow), and it's pretty simple to add to the
engine.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54734&edit=1
