[PHP-BUG] Bug #64531 [NEW]: SQLite3's SQLite3Result::fetchArray runs the query again.
From: phplists at stanvassilev dot com
Operating system: Windows XP SP3 32bit
PHP version: 5.4.13
Package: SQLite related
Bug Type: Bug
Bug description:SQLite3's SQLite3Result::fetchArray runs the query again.
Description:
I was quite surprised to find that, but SQLite3 results cause the query to
execute
a second time when you try to fetch from them (after the query() call).
This is not just a harmless performance issue. When the query is an INSERT
query,
it causes duplicate rows, and creates all kinds of other messes.
IMPORTANT: If you perform the same tests with the SQLite3 driver for PDO,
it
doesn't have this issue (fetching results won't cause the query to run
again). The
issue is specific to the SQLite3 extension.
Test script:
---
EXAMPLE1:
I caught that when I run an INSERT query through a generic routine which
always uses query() and then runs fetchArray() in a loop to see if
something was returned. Naturally INSERT queries return nothing, but trying
to fetch on an empty result set should NOT produce side effects:
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$res = $conn->query('INSERT INTO Table VALUES(null, 1, 2, 3'); // Inserts a
row here (the null is an auto-incrementing PK).
$res->fetchArray()); // Inserts the *same* row data as above, again (with
the next auto-incrementing PK number).
$res->fetchArray()); // And yet again...
EXAMPLE2:
Another way to prove that something is fishy, is by registering a PHP
function for use in SQLite3. Let's say we have a table with a column "id",
and we have three rows, with "id" values 1, 2, 3.
function testing($val) {
echo 'Testing with: ' . $val . '';
return true;
}
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$conn->createFunction('testing', 'testing', 1);
$res = $conn->query('SELECT * FROM Table WHERE testing(id)'); // "Testing
with: 1"
$arr = $res->fetchArray(); // "Testing with: 1" (notice the repetition of 1
with the query above, this shouldn't occur).
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
// At this point the next call to fetchArray() will return false, as it
should. But what's happening internally? Something else:
$arr = $res->fetchArray(); // "Testing with: 1" again. Huh? Why is it
running that again?
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
$arr = $res->fetchArray(); // "Testing with: 1"
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
// ...and so on forever.
Another used has encountered an issue like this over 6 months ago (!) which
means this bug has been around for a while:
http://stackoverflow.com/questions/12981332/php-sqlite3resultfetcharray-re-executes-query
Expected result:
The SQLite3 extension should execute a query once, and each row of the
result set
should be executed once, like PDO's SQLite3 driver does.
Fetching should cause duplicate INSERTS and twice computed results.
Actual result:
--
The SQLite3 extension executes the query again when fetching from the
result set.
--
Edit bug report at https://bugs.php.net/bug.php?id=64531&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64531&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64531&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64531&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64531&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64531&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64531&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64531&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64531&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64531&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64531&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64531&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64531&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64531&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64531&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64531&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64531&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64531&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64531&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64531&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64531&r=mysqlcfg
Bug #64531 [Opn]: SQLite3's SQLite3Result::fetchArray runs the query again.
Edit report at https://bugs.php.net/bug.php?id=64531&edit=1
ID: 64531
User updated by:phplists at stanvassilev dot com
Reported by:phplists at stanvassilev dot com
Summary:SQLite3's SQLite3Result::fetchArray runs the query
again.
Status: Open
Type: Bug
Package:SQLite related
Operating System: Windows XP SP3 32bit
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
I hate when that happens, although I guess I'm clear:
Typo in Expected Result: "Fetching should cause duplicate";
should be:"Fetching should NOT cause duplicate";
Typo in EXAMPLE2: "Another used has encountered an issue like"
should be: "Another user has encountered an issue like"
Previous Comments:
------------
[2013-03-27 09:20:31] phplists at stanvassilev dot com
Description:
I was quite surprised to find that, but SQLite3 results cause the query to
execute
a second time when you try to fetch from them (after the query() call).
This is not just a harmless performance issue. When the query is an INSERT
query,
it causes duplicate rows, and creates all kinds of other messes.
IMPORTANT: If you perform the same tests with the SQLite3 driver for PDO, it
doesn't have this issue (fetching results won't cause the query to run again).
The
issue is specific to the SQLite3 extension.
Test script:
---
EXAMPLE1:
I caught that when I run an INSERT query through a generic routine which always
uses query() and then runs fetchArray() in a loop to see if something was
returned. Naturally INSERT queries return nothing, but trying to fetch on an
empty result set should NOT produce side effects:
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$res = $conn->query('INSERT INTO Table VALUES(null, 1, 2, 3'); // Inserts a row
here (the null is an auto-incrementing PK).
$res->fetchArray()); // Inserts the *same* row data as above, again (with the
next auto-incrementing PK number).
$res->fetchArray()); // And yet again...
EXAMPLE2:
Another way to prove that something is fishy, is by registering a PHP function
for use in SQLite3. Let's say we have a table with a column "id", and we have
three rows, with "id" values 1, 2, 3.
function testing($val) {
echo 'Testing with: ' . $val . '';
return true;
}
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$conn->createFunction('testing', 'testing', 1);
$res = $conn->query('SELECT * FROM Table WHERE testing(id)'); // "Testing with:
1"
$arr = $res->fetchArray(); // "Testing with: 1" (notice the repetition of 1
with the query above, this shouldn't occur).
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
// At this point the next call to fetchArray() will return false, as it should.
But what's happening internally? Something else:
$arr = $res->fetchArray(); // "Testing with: 1" again. Huh? Why is it running
that again?
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
$arr = $res->fetchArray(); // "Testing with: 1"
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
// ...and so on forever.
Another used has encountered an issue like this over 6 months ago (!) which
means this bug has been around for a while:
http://stackoverflow.com/questions/12981332/php-sqlite3resultfetcharray-re-executes-query
Expected result:
The SQLite3 extension should execute a query once, and each row of the result
set
should be executed once, like PDO's SQLite3 driver does.
Fetching should cause duplicate INSERTS and twice computed results.
Actual result:
--
The SQLite3 extension executes the query again when fetching from the result
set.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64531&edit=1
Bug #64531 [Com]: SQLite3's SQLite3Result::fetchArray runs the query again.
Edit report at https://bugs.php.net/bug.php?id=64531&edit=1
ID: 64531
Comment by: phplists at stanvassilev dot com
Reported by:phplists at stanvassilev dot com
Summary:SQLite3's SQLite3Result::fetchArray runs the query
again.
Status: Open
Type: Bug
Package:SQLite related
Operating System: Windows XP SP3 32bit
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
Before people start recommending a documentation "fix", be aware that I have
two
examples.
The first use case is solved by using exec(). The second is solved by nothing,
the query is evaluated twice. Those are just two examples demonstrating the
same
issue.
Don't try to fix my examples, try to fix the issue. The culprit seems to be
that
_step is executed for the query once on query(), but then it's executed all
over
again on first fetch, starting at row1 again.
A proposed solution fixing all side effects would be to run step() on query()
and cache the fetched result, then return it on first fetch, then call step()
on
second fetch etc.:
query(...); // call sqlite3_step, save row1
fetchArray(...); // return saved row1
fetchArray(...); // call sqlite3_step, return row2
fetchArray(...); // call sqlite3_step, return row3
fetchArray(...); // call sqlite3_step, return row4
...
Previous Comments:
[2013-03-27 16:44:23] frozenf...@php.net
The related source is: https://github.com/php/php-
src/blob/master/ext/sqlite3/sqlite3.c#L1725
The solution to this bug might simply have to be a documentation note
indicating
the SQLite3::exec should be used for inserts instead of SQLite3::query, as
::query will necessarily re-execute to "step" through.
----
[2013-03-27 09:25:40] phplists at stanvassilev dot com
I hate when that happens, although I guess I'm clear:
Typo in Expected Result: "Fetching should cause duplicate";
should be:"Fetching should NOT cause duplicate";
Typo in EXAMPLE2: "Another used has encountered an issue like"
should be: "Another user has encountered an issue like"
----------------
[2013-03-27 09:20:31] phplists at stanvassilev dot com
Description:
I was quite surprised to find that, but SQLite3 results cause the query to
execute
a second time when you try to fetch from them (after the query() call).
This is not just a harmless performance issue. When the query is an INSERT
query,
it causes duplicate rows, and creates all kinds of other messes.
IMPORTANT: If you perform the same tests with the SQLite3 driver for PDO, it
doesn't have this issue (fetching results won't cause the query to run again).
The
issue is specific to the SQLite3 extension.
Test script:
---
EXAMPLE1:
I caught that when I run an INSERT query through a generic routine which always
uses query() and then runs fetchArray() in a loop to see if something was
returned. Naturally INSERT queries return nothing, but trying to fetch on an
empty result set should NOT produce side effects:
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$res = $conn->query('INSERT INTO Table VALUES(null, 1, 2, 3'); // Inserts a row
here (the null is an auto-incrementing PK).
$res->fetchArray()); // Inserts the *same* row data as above, again (with the
next auto-incrementing PK number).
$res->fetchArray()); // And yet again...
EXAMPLE2:
Another way to prove that something is fishy, is by registering a PHP function
for use in SQLite3. Let's say we have a table with a column "id", and we have
three rows, with "id" values 1, 2, 3.
function testing($val) {
echo 'Testing with: ' . $val . '';
return true;
}
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$conn->createFunction('testing', 'testing', 1);
$res = $conn->query('SELECT * FROM Table WHERE testing(id)'); // "Testing with:
1"
$arr = $res->fetchArray(); // "Testing with: 1" (notice the repetition of 1
with the query above, this shouldn't occur).
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
// At this point the next call to fetchArray() will return false, as it should.
But what's happening internally? Something else:
$arr = $res->fetchArray(); // "Testing with: 1" again. Huh? Why is it running
that again?
$arr = $res->fetchArray(); // "Testing with: 2"
$arr = $res->fetchArray(); // "Testing with: 3"
$arr = $res->fetchArray(
Bug #64531 [Com]: SQLite3's SQLite3Result::fetchArray runs the query again.
Edit report at https://bugs.php.net/bug.php?id=64531&edit=1
ID: 64531
Comment by: phplists at stanvassilev dot com
Reported by:phplists at stanvassilev dot com
Summary:SQLite3's SQLite3Result::fetchArray runs the query
again.
Status: Open
Type: Bug
Package:SQLite related
Operating System: Windows XP SP3 32bit
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
I've been discussing this in #PHP.PECL, with auroraeos and others and basically
the problem is caused by the OOP interface in the binding.
The binding introduces extra logic so query() in PHP can return a resultset
object or false etc.
In order to know what to return, query() calls sqlite3_step() which fetches the
first row of the result.
So far so good. Here's the problem:
The binding then *resets* the query so the first call to fetchArray() returns
row1 again. This is not library behavior, it's binding behavior that's
additional logic.
This causes row1 to be computed twice, and queries to run twice etc.
The solution for solving this without introducing BC breaks and interface
breaks, is for the binding to store the row it fetched during query() with the
resultset, as outlined in my previous comment, and return it on first call to
fetchArray, without calling step.
On subsequent calls to fetchArray(), step is called to fetch the other rows.
Either way you look at it, the binding added behavior that isn't in the
original
library, and this is causing performance issues and side effects. The
responsible thing is to keep the PHP OOP interface compatible, but fix the
performance issues and side effects.
And what I described is how to do it...
Previous Comments:
----
[2013-03-27 16:59:58] phplists at stanvassilev dot com
Before people start recommending a documentation "fix", be aware that I have
two
examples.
The first use case is solved by using exec(). The second is solved by nothing,
the query is evaluated twice. Those are just two examples demonstrating the
same
issue.
Don't try to fix my examples, try to fix the issue. The culprit seems to be
that
_step is executed for the query once on query(), but then it's executed all
over
again on first fetch, starting at row1 again.
A proposed solution fixing all side effects would be to run step() on query()
and cache the fetched result, then return it on first fetch, then call step()
on
second fetch etc.:
query(...); // call sqlite3_step, save row1
fetchArray(...); // return saved row1
fetchArray(...); // call sqlite3_step, return row2
fetchArray(...); // call sqlite3_step, return row3
fetchArray(...); // call sqlite3_step, return row4
...
[2013-03-27 16:44:23] frozenf...@php.net
The related source is: https://github.com/php/php-
src/blob/master/ext/sqlite3/sqlite3.c#L1725
The solution to this bug might simply have to be a documentation note
indicating
the SQLite3::exec should be used for inserts instead of SQLite3::query, as
::query will necessarily re-execute to "step" through.
----------------
[2013-03-27 09:25:40] phplists at stanvassilev dot com
I hate when that happens, although I guess I'm clear:
Typo in Expected Result: "Fetching should cause duplicate";
should be:"Fetching should NOT cause duplicate";
Typo in EXAMPLE2: "Another used has encountered an issue like"
should be: "Another user has encountered an issue like"
------------
[2013-03-27 09:20:31] phplists at stanvassilev dot com
Description:
I was quite surprised to find that, but SQLite3 results cause the query to
execute
a second time when you try to fetch from them (after the query() call).
This is not just a harmless performance issue. When the query is an INSERT
query,
it causes duplicate rows, and creates all kinds of other messes.
IMPORTANT: If you perform the same tests with the SQLite3 driver for PDO, it
doesn't have this issue (fetching results won't cause the query to run again).
The
issue is specific to the SQLite3 extension.
Test script:
---
EXAMPLE1:
I caught that when I run an INSERT query through a generic routine which always
uses query() and then runs fetchArray() in a loop to see if something was
returned. Naturally INSERT queries return nothing, but trying to fetch on an
empty result set should NOT produce side effects:
$conn = new SQLite3('Log.sqlite', \SQLITE3_OPEN_READWRITE);
$res = $conn->query('INSERT INTO Table VALUES(null, 1, 2, 3'); // Inserts a row
here (the null is an auto-increme
[PHP-BUG] Bug #62042 [NEW]: Fatal error when merging files due to class/function/symbol name collision
From:
Operating system: All
PHP version: 5.3.13
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Fatal error when merging files due to class/function/symbol
name collision
Description:
These two namespaces work as expected when in two separate files, and when
included together at runtime work as expected as well, but once they're
merged
in the same file they result in a Fatal Error:
namespace Foo {
class Bar {}
}
namespace Foo {
use Bar;
}
Fatal error: Cannot use Bar as Bar because the name is already in use.
I understand this behavior was introduced with good intentions, but all it
does
is break working code when files are merged together. The alternative
namespace
construct was introduced specifically to support merging of multiple files
together without side effects, and this is such a side effect.
Expected result:
I expect that "use" statements should override default resolutions, and no
Fatal
Error should be produced (the EXACT behavior we have right now when the
above is
spread in two files which are required() at runtime).
Actual result:
--
Fatal Error when merging code.
--
Edit bug report at https://bugs.php.net/bug.php?id=62042&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62042&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62042&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62042&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62042&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62042&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62042&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62042&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62042&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62042&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62042&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62042&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62042&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62042&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62042&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62042&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62042&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62042&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62042&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62042&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62042&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62042&r=mysqlcfg
[PHP-BUG] Bug #62076 [NEW]: Global/namespace constants are not hoisted
From: Operating system: PHP version: 5.4.3 Package: Scripting Engine problem Bug Type: Bug Bug description:Global/namespace constants are not hoisted Description: "const" Declarations outside a class were introduced in PHP 5.3, and they only support static "compile-time" expressions, unlike define(). Function and classes declarations are hoisted to the top of the file, so you can call them before the line they are defined in. This doesn't happen with "const", although it's expected as a matter of consistency. This leads to the following odd problem: https://bugs.php.net/bug.php?id=62076&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62076&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62076&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62076&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62076&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62076&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62076&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62076&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62076&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62076&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62076&r=support Expected behavior: https://bugs.php.net/fix.php?id=62076&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62076&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62076&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62076&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62076&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62076&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62076&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62076&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62076&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62076&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62076&r=mysqlcfg
Bug #62076 [Opn]: Global/namespace constants are not hoisted
Edit report at https://bugs.php.net/bug.php?id=62076&edit=1 ID: 62076 User updated by:phplists at stanvassilev dot com Reported by:phplists at stanvassilev dot com Summary:Global/namespace constants are not hoisted Status: Open Type: Bug Package:Scripting Engine problem PHP Version:5.4.3 Block user comment: N Private report: N New Comment: My full argument why const should be hoisted, while define() can't and shouldn't be: const FOO = val; is a construct that doesn't depend on runtime conditions, much like class constants. It can't accept expressions, variables and can't be placed in conditional blocks, while define() is a function call that can accept variables and expressions and be placed in conditional blocks. Therefore regardless of their opcode implementation, they are exposed in a fundamentally different way, and define() hoisting isn't expected while const hoisting is expected (as a static declaration, and similar to class const declaration, their position in the class DOES NOT matter). Therefore I believe const should act like class constants, and not like define(), as this matches user expectations better. Previous Comments: ---- [2012-05-20 10:28:28] phplists at stanvassilev dot com Description: "const" Declarations outside a class were introduced in PHP 5.3, and they only support static "compile-time" expressions, unlike define(). Function and classes declarations are hoisted to the top of the file, so you can call them before the line they are defined in. This doesn't happen with "const", although it's expected as a matter of consistency. This leads to the following odd problem: https://bugs.php.net/bug.php?id=62076&edit=1
[PHP-BUG] Bug #62634 [NEW]: Incorrect serialization with circular references
From: phplists at stanvassilev dot com
Operating system: Any
PHP version: 5.4.5
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Incorrect serialization with circular references
Description:
The documentation says references and circular references should serialize
properly. I've found that serialize would first copy the referenced
variable,
before detecting the reference.
This not only doubles the serialized output, but produced incorrect copy
when
unserialized.
Test script:
---
$original = array('hello');
$original[] = & $original;
echo serialize($original);
// Output (notice the duplication):
// "a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
$duplicate = unserialize(serialize($x));
// Now I modify both the original and the duplicate in an identical way.
// But I get different results, because the duplicate points to a copy of
// itself, instead of pointing to itself.
$original[0] = 'world';
$duplicate[0] = 'world';
var_dump($original);
// Produces (notice it says "world" both times, i.e. it points to itself):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5)
"world" [1]=> *RECURSION* } }
var_dump($duplicate);
// Produces (notice the second time it says "hello" i.e. it's a copy):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5)
"hello" [1]=> *RECURSION* } }
Expected result:
There should be NO copies of "hello" left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5)
"world" [1]=>
*RECURSION* } }
There should be NO duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;???;}" (Fill-in the "???" appropriately :) )
Actual result:
--
A copy of "hello" is left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5)
"hello" [1]=>
*RECURSION* } }
There is duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
--
Edit bug report at https://bugs.php.net/bug.php?id=62634&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62634&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62634&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62634&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62634&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62634&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62634&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62634&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62634&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62634&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62634&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62634&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62634&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62634&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62634&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62634&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62634&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62634&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62634&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62634&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62634&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62634&r=mysqlcfg
Bug #62634 [Opn]: Incorrect serialization with circular references
Edit report at https://bugs.php.net/bug.php?id=62634&edit=1
ID: 62634
User updated by:phplists at stanvassilev dot com
Reported by:phplists at stanvassilev dot com
Summary:Incorrect serialization with circular references
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
There's a small error in my code example, please replace this line:
$duplicate = unserialize(serialize($x));
With this line:
$duplicate = unserialize(serialize($original));
Previous Comments:
[2012-07-22 21:54:54] phplists at stanvassilev dot com
Description:
The documentation says references and circular references should serialize
properly. I've found that serialize would first copy the referenced variable,
before detecting the reference.
This not only doubles the serialized output, but produced incorrect copy when
unserialized.
Test script:
---
$original = array('hello');
$original[] = & $original;
echo serialize($original);
// Output (notice the duplication):
// "a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
$duplicate = unserialize(serialize($x));
// Now I modify both the original and the duplicate in an identical way.
// But I get different results, because the duplicate points to a copy of
// itself, instead of pointing to itself.
$original[0] = 'world';
$duplicate[0] = 'world';
var_dump($original);
// Produces (notice it says "world" both times, i.e. it points to itself):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world"
[1]=> *RECURSION* } }
var_dump($duplicate);
// Produces (notice the second time it says "hello" i.e. it's a copy):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello"
[1]=> *RECURSION* } }
Expected result:
There should be NO copies of "hello" left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world"
[1]=>
*RECURSION* } }
There should be NO duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;???;}" (Fill-in the "???" appropriately :) )
Actual result:
--
A copy of "hello" is left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello"
[1]=>
*RECURSION* } }
There is duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
--
Edit this bug report at https://bugs.php.net/bug.php?id=62634&edit=1
#48418 [NEW]: NaN > NaN, NaN > 0, NaN < 0 return true
From: phplists at stanvassilev dot com Operating system: Linux, BSD, possibly all *nix PHP version: 5.2.9 PHP Bug Type: Math related Bug description: NaN > NaN, NaN > 0, NaN < 0 return true Description: Tested on Gentoo, CentOS, OSX. This is possibly NOT related to the Windows NaN bug, as Windows is NOT affected by this issue. However, please test if any fix doesn't cause regression on Windows. NaN > NaN, NaN > 0, NaN < 0 return true, while they should return false in all cases (any comparison where either side is NaN, should return false). Reproduce code: --- $NaN = sqrt(-1); var_dump($NaN > $NaN); var_dump($NaN > 0); var_dump($NaN < 0); Expected result: float(NAN) bool(false) bool(false) bool(false) Actual result: -- float(NAN) bool(true) bool(true) bool(true) -- Edit bug report at http://bugs.php.net/?id=48418&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48418&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48418&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48418&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48418&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48418&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48418&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48418&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48418&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48418&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48418&r=support Expected behavior: http://bugs.php.net/fix.php?id=48418&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48418&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48418&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48418&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48418&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48418&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48418&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48418&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48418&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48418&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48418&r=mysqlcfg
#48418 [Com]: NaN > NaN, NaN > 0, NaN < 0 return true
ID: 48418 Comment by: phplists at stanvassilev dot com Reported By: phplists at stanvassilev dot com Status: Open Bug Type: Math related Operating System: Linux, BSD, possibly all *nix PHP Version: 5.2.9 New Comment: And to add a note: $NaN >= $NaN $NaN >= 0 $NaN <= 0 These also return true and must return false. Previous Comments: [2009-05-28 18:57:57] phplists at stanvassilev dot com Description: Tested on Gentoo, CentOS, OSX. This is possibly NOT related to the Windows NaN bug, as Windows is NOT affected by this issue. However, please test if any fix doesn't cause regression on Windows. NaN > NaN, NaN > 0, NaN < 0 return true, while they should return false in all cases (any comparison where either side is NaN, should return false). Reproduce code: --- $NaN = sqrt(-1); var_dump($NaN > $NaN); var_dump($NaN > 0); var_dump($NaN < 0); Expected result: float(NAN) bool(false) bool(false) bool(false) Actual result: -- float(NAN) bool(true) bool(true) bool(true) -- Edit this bug report at http://bugs.php.net/?id=48418&edit=1
[PHP-BUG] Req #53038 [NEW]: Enhancement / change to array_flip() with boolean values
From:
Operating system: Any
PHP version: 5.3.3
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Enhancement / change to array_flip() with boolean values
Description:
This is not a bug, but I propose a change to how array_flip operates with
boolean values, in order to improve common use cases, because:
1) The current behavior (warning and completely empty array) renders arrays
with
one or more boolean values invalid for flipping so they have to be manually
filtered in advance.
2) When true/false are cast to 1/0, all loose type checks against the keys
will
match (i.e. true == 1, false == 0) which makes the cast also a practical
one for
real utility.
3) The change will make the casting behavior of array_flip consistent with
the
*already* existing behavior in the following example:
// casts booleans to int, and produces: array(1 => 123, 0 => 321);
$a = array(); $a[true] = 123; $a[false] = 321;
Test script:
---
var_dump(
array_flip(
array('foo' => true, 'bar' => false)
)
);
Expected result:
array(2) { [1]=> string(3) "foo" [0]=> string(3) "bar" }
Actual result:
--
Warning: array_flip() [function.array-flip]: Can only flip STRING and
INTEGER
values! in ... on line 2
array(0) { }
--
Edit bug report at http://bugs.php.net/bug.php?id=53038&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53038&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53038&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53038&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53038&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53038&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53038&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53038&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53038&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53038&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53038&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53038&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53038&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53038&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53038&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53038&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53038&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53038&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53038&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53038&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53038&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53038&r=mysqlcfg
[PHP-BUG] Bug #53432 [NEW]: String index access on empty string converts to array
From: Operating system: All PHP version: 5.2.14 Package: Unknown/Other Function Bug Type: Bug Bug description:String index access on empty string converts to array Description: The title/code says it all. Once a variable is a string, using array access should mean char access, but this is not maintained for empty strings, while it's maintained for non-empty strings. Test script: --- $a = ''; // empty string $a[10] = 'a'; echo $a; // "Array" $b = ' '; // non empty string $b[10] = 'b'; echo $b; // " b" Expected result: " a" " b" Actual result: -- "Array" " b" -- Edit bug report at http://bugs.php.net/bug.php?id=53432&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53432&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53432&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53432&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53432&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53432&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53432&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53432&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53432&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53432&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53432&r=support Expected behavior: http://bugs.php.net/fix.php?id=53432&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53432&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53432&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53432&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53432&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53432&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53432&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53432&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53432&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53432&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53432&r=mysqlcfg
Bug #53432 [Opn]: Assignment via string index access on an empty string converts to array
Edit report at http://bugs.php.net/bug.php?id=53432&edit=1 ID: 53432 User updated by:phplists at stanvassilev dot com Reported by:phplists at stanvassilev dot com -Summary:String index access on empty string converts to array +Summary:Assignment via string index access on an empty string converts to array Status: Open Type: Bug Package:Unknown/Other Function Operating System: All PHP Version:5.2.14 Block user comment: N Private report: N New Comment: I want to note, I realize when the variable is undefined, null, false, array is the expected end result, but a string is already signifying explicitly the intent of the programmer. While PHP is a language with loose typing, it's not as loose as to convert scalars to arrays and back, despite a set value. Previous Comments: [2010-12-01 04:19:40] phplists at stanvassilev dot com Description: The title/code says it all. Once a variable is a string, using array access should mean char access, but this is not maintained for empty strings, while it's maintained for non-empty strings. Test script: --- $a = ''; // empty string $a[10] = 'a'; echo $a; // "Array" $b = ' '; // non empty string $b[10] = 'b'; echo $b; // " b" Expected result: " a" " b" Actual result: -- "Array" " b" -- Edit this bug report at http://bugs.php.net/bug.php?id=53432&edit=1
