[PHP-BUG] Bug #60801 [NEW]: strpbrk() mishandles NUL byte
From: Operating system: PHP version: 5.3.9 Package: Class/Object related Bug Type: Bug Bug description:strpbrk() mishandles NUL byte Description: PHP's strpbrk() passes its string arguments directly to libc strpbrk(), which considers NUL byte a string-terminatig character rather than a normal part of the string. note that, in the test script below, the strpbrk() matches neither the NUL byte, nor the `a' character (because it occurs after a NUL byte in $haystack), nor even the `b' character (because it occurs after a NUL byte in $char_list). Test script: --- $haystack = "foob\x00ar"; $char_list = "a\x00b"; $v = strpbrk($haystack, $char_list); Expected result: $v === "b\x00ar" Actual result: -- $v === FALSE -- Edit bug report at https://bugs.php.net/bug.php?id=60801&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60801&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60801&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60801&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60801&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60801&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60801&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60801&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60801&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60801&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60801&r=support Expected behavior: https://bugs.php.net/fix.php?id=60801&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60801&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60801&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60801&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60801&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60801&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60801&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60801&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60801&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60801&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60801&r=mysqlcfg
Bug #60801 [Sus]: strpbrk() mishandles NUL byte
Edit report at https://bugs.php.net/bug.php?id=60801&edit=1 ID: 60801 User updated by:dexen dot devries at gmail dot com Reported by:dexen dot devries at gmail dot com Summary:strpbrk() mishandles NUL byte Status: Suspended Type: Bug Package:Strings related PHP Version:5.3.9 Assigned To:aharvey Block user comment: N Private report: N New Comment: thanks for the quick fix, aharvey :-) Previous Comments: [2012-01-30 13:30:22] ahar...@php.net Implemented on trunk. This should be straightforward enough to backport to 5.3 and 5.4, but with 5.4 in code freeze at present, I'll have to revisit this a bit after 5.4.0 final is released. [2012-01-30 13:29:13] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=322934 Log: Fix bug #60801 (strpbrk() mishandles NUL byte) on trunk only for now. [2012-01-19 09:37:07] dexen dot devries at gmail dot com Description: PHP's strpbrk() passes its string arguments directly to libc strpbrk(), which considers NUL byte a string-terminatig character rather than a normal part of the string. note that, in the test script below, the strpbrk() matches neither the NUL byte, nor the `a' character (because it occurs after a NUL byte in $haystack), nor even the `b' character (because it occurs after a NUL byte in $char_list). Test script: --- $haystack = "foob\x00ar"; $char_list = "a\x00b"; $v = strpbrk($haystack, $char_list); Expected result: $v === "b\x00ar" Actual result: -- $v === FALSE -- Edit this bug report at https://bugs.php.net/bug.php?id=60801&edit=1
[PHP-BUG] Req #62778 [NEW]: pre-increment operator produces rvalue rather than lvalue
From: dexen dot devries at gmail dot com
Operating system:
PHP version: 5.4.6RC1
Package: Variables related
Bug Type: Feature/Change Request
Bug description:pre-increment operator produces rvalue rather than lvalue
Description:
Result of pre-increment (also pre-decrement) operator is a value (`rvalue')
rather than a reference to variable (`lvalue'). This prevents assigning
result of the operator to reference, or passing it by reference.
There is no apparent reason for such limitation; the operator only applies
to variables (never to other expressions), and PHP core supports
references.
The requested behavior is similar to C++ (result of pre-increment operator
is reference); the current behavior mimics C (result of pre-increment
operator is an rvalue).
Test script:
---
$a = 0;
$b = 0;
$c = 0;
function foo(&$v) {
$v = $v + 1;
}
++$a;
foo($a);
var_dump($a);
foo(++$b);
var_dump($b);
$b =& ++$c;
var_dump($c);
Expected result:
$a === 2
$b === 2
$c === 1
Actual result:
--
$a === 2
Strict Standards: Only variables should be passed by reference
$b === 1
PHP Parse error: syntax error, unexpected '++' (T_INC)
--
Edit bug report at https://bugs.php.net/bug.php?id=62778&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62778&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62778&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62778&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62778&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62778&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62778&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62778&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62778&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62778&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62778&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62778&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62778&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62778&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62778&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62778&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62778&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62778&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62778&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62778&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62778&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62778&r=mysqlcfg
[PHP-BUG] Bug #63021 [NEW]: var_export() does not export Closures
From: dexen dot devries at gmail dot com
Operating system:
PHP version: 5.4.6
Package: *Programming Data Structures
Bug Type: Bug
Bug description:var_export() does not export Closures
Description:
While var_dump() produces sensible output for Closures, output of the
var_export() is pretty much useless.
Test script:
---
array(1) {
["a"]=>
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
}
["parameter"]=>
array(1) {
["$n"]=>
string(10) ""
}
}
(((resembling the following:)))
object(Closure)#1 (2) {
["static"]=>
array(1) {
["a"]=>
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
}
["parameter"]=>
array(1) {
["$n"]=>
string(10) ""
}
}
Actual result:
--
object(Closure)#1 (2) {
["static"]=>
array(1) {
["a"]=>
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
}
["parameter"]=>
array(1) {
["$n"]=>
string(10) ""
}
}
Closure::__set_state(array(
))
--
Edit bug report at https://bugs.php.net/bug.php?id=63021&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63021&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63021&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63021&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63021&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=63021&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63021&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=63021&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=63021&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=63021&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=63021&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=63021&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63021&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63021&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=63021&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=63021&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=63021&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=63021&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=63021&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=63021&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=63021&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=63021&r=mysqlcfg
[PHP-BUG] Bug #63185 [NEW]: nextRowset() ignores MySQL errors
From: dexen dot devries at gmail dot com
Operating system: linux
PHP version: 5.4.7
Package: PDO related
Bug Type: Bug
Bug description:nextRowset() ignores MySQL errors
Description:
An SQL stored procedure will return several rowsets when it contains
several SELECT statements. In MySQL CLI client (`mysql'), if any statement
raises SQL error, the procedure is aborted, HOWEVER, all rowsets prior to
the error are displayed.
In PHP, PDO->nextRowset() switches to subsequent rowsets, or indicates no
more rowsets with `FALSE'. However, it ignores SQL errors in second and
later SQL statements.
For reproduction, the following SQL procedures refer to nonexistent table
`no_such_table'.
For reference SQL program for MySQL CLI client (`mysql') -- which correctly
indicates errors.
<>:
DROP TABLE IF EXISTS test_table;
DROP TABLE IF EXISTS no_such_table;
DROP PROCEDURE IF EXISTS test_procedure_error_at_first;
DROP PROCEDURE IF EXISTS test_procedure_error_at_second;
CREATE TABLE test_table (aaa int PRIMARY KEY);
INSERT INTO test_table SELECT 1 UNION SELECT 2;
DELIMITER $$
CREATE PROCEDURE test_procedure_error_at_first ()
BEGIN
SELECT * FROM no_such_table; -- will raise error
SELECT * FROM test_table;
END;
CALL test_procedure_error_at_first $$
CREATE PROCEDURE test_procedure_error_at_second ()
BEGIN
SELECT * FROM test_table;
SELECT * FROM no_such_table; -- will raise error
END;
CALL test_procedure () $$
<>:
ERROR 1146 (42S02): Table 'no_such_table' doesn't exist
<>:
+-+
| aaa |
+-+
| 1 |
| 2 |
+-+
2 rows in set (0.00 sec)
ERROR 1146 (42S02): Table 'no_such_table' doesn't exist
Test script:
---
setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->exec('DROP TABLE IF EXISTS test_table');
$pdo->exec('DROP TABLE IF EXISTS no_such_table');
$pdo->exec('DROP PROCEDURE IF EXISTS test_procedure_error_at_first');
$pdo->exec('DROP PROCEDURE IF EXISTS test_procedure_error_at_second');
$pdo->exec('CREATE TABLE test_table (aaa int PRIMARY KEY)');
$pdo->exec('INSERT INTO test_table SELECT 1 UNION SELECT 2');
$pdo->exec('CREATE PROCEDURE test_procedure_error_at_first ()
BEGIN
SELECT * FROM no_such_table; -- will raise error
SELECT * FROM test_table;
END');
$pdo->exec('CREATE PROCEDURE test_procedure_error_at_second ()
BEGIN
SELECT * FROM test_table;
SELECT * FROM no_such_table; -- this SHOULD raise error, but
will be
IGNORED
END');
# this would correctly indicate error raised by first SELECT * FROM
no_such_table by raising an PDOException
#$pdo->query('CALL test_procedure_error_at_first()');
$st = $pdo->query('CALL test_procedure_error_at_second()');
# this correctly fetches data from first SELECT * FROM test_table
var_dump($st->fetchAll());
# this IGNORES error raised by second SELECT * FROM no_such_table
var_dump($st->nextRowset());
var_dump($st->fetchAll());
Expected result:
array(2) { [0]=> array(2) { ["aaa"]=> int(1) [0]=> int(1) } [1]=> array(2)
{ ["aaa"]=> int(2) [0]=> int(2) } } # from var_dump($st->fetchAll());
PDOException: Base table or view not found: 1146 Table 'no_such_table'
doesn't exist # from $pdo->nextRowset()
Actual result:
--
array(2) { [0]=> array(2) { ["aaa"]=> int(1) [0]=> int(1) } [1]=> array(2)
{ ["aaa"]=> int(2) [0]=> int(2) } } # from var_dump($st->fetchAll());
bool(false) # from var_dump($st->nextRowset());
array(0) { }# from var_dump($st->fetchAll());
--
Edit bug report at https://bugs.php.net/bug.php?id=63185&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63185&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63185&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63185&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63185&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63185&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63185&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63185&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63185&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63185&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63185&r=notwrong
Not enough i
