Bug #65227 [Opn]: Memory leak in gmp_cmp second parameter
Edit report at https://bugs.php.net/bug.php?id=65227&edit=1 ID: 65227 Updated by: frozenf...@php.net Reported by:frozenf...@php.net Summary:Memory leak in gmp_cmp second parameter Status: Open Type: Bug Package:GNU MP related Operating System: Irrelevant PHP Version:unknown Block user comment: N Private report: N New Comment: I noticed shortly after filing the bug that this issue *may* be resolved as of https://github.com/php/php- src/commit/7713b8c2ac2d8fbacaf897ff0c0a202a7b7abf49#ext/gmp/gmp.c The issue may have resulted from the lack of a free of temp_b after https://github.com/php/php- src/blob/a666285bc2488b7f7362368c388e41428610ad1d/ext/gmp/gmp.c#L1337, which would apply to all versions except 5.next Previous Comments: [2013-07-09 16:17:47] frozenf...@php.net Description: Reporting this bug for a third party (http://www.reddit.com/r/PHP/comments/1hx7qz/what_is_going_on_here_how_do_i_fix_t his_memory/), and related to a user note (http://www.php.net/manual/en/function.gmp-cmp.php#99120). The gmp_cmp function leaks memory when a string is used as the value of the second parameter. My guess is that it relates to the way that the type is juggled in the gmp_cmp function (https://github.com/php/php-src/blob/master/ext/gmp/gmp.c#L848), where it checks the type of the second parameter to see if it's a long. It doesn't however check if the second parameter is a string, or really any other type. Test script: --- Third party's example code can be found at http://www.reddit.com/r/PHP/comments/1hx7qz/what_is_going_on_here_how_do_i_fix_this_memory/ -- Edit this bug report at https://bugs.php.net/bug.php?id=65227&edit=1
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
Updated by: frozenf...@php.net
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:
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.
Previous Comments:
[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(); // "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
Req #41243 [Asn]: How to use ZIPARCHIVE::CM_STORE
Edit report at https://bugs.php.net/bug.php?id=41243&edit=1 ID: 41243 Updated by: frozenf...@php.net Reported by:joel dot alexandre at gmail dot com Summary:How to use ZIPARCHIVE::CM_STORE Status: Assigned Type: Feature/Change Request Package:Zip Related PHP Version:5.x Assigned To:pajoye Block user comment: N Private report: N New Comment: Any progress on this, pajoye? Given the number of votes on this bug, and its age, I think this needs to be addressed as soon as possible. I encountered this bug today, and it's quite frustrating to not be able to set the compression level. Previous Comments: [2012-01-23 10:57:54] mpeters at domblogger dot net It is imperative that this bug be addressed and fixed. The epub specification requires that the first file in the zip archive be named mimetype and be uncompressed. Until this bug is fixed, it is thus impossible to create a valid epub file in pure php w/o executing system commands (forbidden in many environments). *maybe* it could be worked around by having a skeleton zip archive with the mimetype file in it uncompressed, but really, we need to be able to create a fresh zip archive, add that file, with no compression. [2010-07-02 14:20:03] php at atis dot id dot lv This would be quite nice for me too. No compression could be useful for creating large archives of multiple files on the fly. [2010-06-04 17:44:31] shockmaker at hotmail dot com I'm looking to create a zip file with a compression level of 0 on some files. So this feature is essential for me. [2010-03-16 04:53:19] jotunbane at gmail dot com 3 years and still no solution to this? Dude you are holding back an entire industry here (exaggeration, I know). Can somebody come up with a workaround for this?? [2009-12-13 16:49:59] made at up dot address Please implement the ability to store files uncompressed in a zip archive. Without this, it is not possible to create epub documents using php, as the standards require that a particular file is always added to the archive uncompressed. http://www.idpf.org/2007/ops/OPS_2.0_final_spec.html 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 https://bugs.php.net/bug.php?id=41243 -- Edit this bug report at https://bugs.php.net/bug.php?id=41243&edit=1
Bug #54199 [Opn->Nab]: callin ob_end_... in ob_start callback function cause stack overflow
Edit report at https://bugs.php.net/bug.php?id=54199&edit=1
ID: 54199
Updated by: frozenf...@php.net
Reported by:keidii at gmail dot com
Summary:callin ob_end_... in ob_start callback function
cause stack overflow
-Status: Open
+Status: Not a bug
Type: Bug
Package:Output Control
Operating System: Linux (other not tested)
PHP Version:5.3
Block user comment: N
Private report: N
New Comment:
This is a documented behaviour, that is not a bug. The documentation notes that
affecting the contents or state of the output buffer itself from within the
output buffer callback as an undefined behaviour.
Previous Comments:
[2011-03-09 13:06:06] fel...@php.net
The documentation says: "ob_end_clean(), ob_end_flush(), ob_clean(), ob_flush()
and ob_start() may not be called from a callback function. If you call them
from callback function, the behavior is undefined. If you would like to delete
the contents of a buffer, return "" (a null string) from callback function."
[2011-03-09 01:00:43] keidii at gmail dot com
version change
[2011-03-09 00:39:37] keidii at gmail dot com
Description:
After calling ob_end_{flush|clean}() inside ob callback function
PHP run into infinite call loop. This results in SIGSEGV or SIGILL process
termination caused by stack overflow.
Tested on php 5.2 and 5.3 (apache and cli)
Latest tested version (compiled with debug):
PHP 5.3.5 (cli) (built: Mar 8 2011 23:29:45) (DEBUG)
Copyright (c) 1997-2010 The PHP Group
--
valgrind output fragment:
(always end with stack grow error)
==5925== Process terminating with default action of signal 11 (SIGSEGV)
==5925== Access not within mapped region at address 0xBE363FFC
==5925==at 0x402685B: bcmp (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==5925== Stack overflow in thread 1: can't grow stack to 0xBE363FF0
--
gdb: it crash on random function after stack is full.
[testrun1]
(gdb) r -f obtest.php
Starting program: /tmp/php/php-5.3.5/sapi/cli/php -f obtest.php
[Thread debugging using libthread_db enabled]
[New process 6663]
[New Thread -1210878272 (LWP 6663)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210878272 (LWP 6663)]
zend_parse_va_args (num_args=0, type_spec=0x835d484 "", va=0xbf7620e0, flags=0)
at /tmp/php/php-5.3.5/Zend/zend_API.c:679
679 int arg_count = (int)(zend_uintptr_t)
*(zend_vm_stack_top(TSRMLS_C) - 1);
[testrun2]
(gdb) r -f obtest.php
Starting program: /tmp/php/php-5.3.5/sapi/cli/php -f obtest.php
[Thread debugging using libthread_db enabled]
[New process 6701]
[New Thread -1210427712 (LWP 6701)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210427712 (LWP 6701)]
0xb7e2dc69 in ?? () from /lib/libc.so.6
--
backtrace: (mor than 5k entries)
#0 zend_parse_va_args
#1 0x0820516c in zend_parse_parameters
#2 0x081ae3d4 in zif_ob_end_clean
#3 0x0822fc0c in zend_do_fcall_common_helper_SPEC
#4 0x08233750 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
#5 0x0822f2a9 in execute
#6 0x081f4bc6 in zend_call_function
#7 0x081f3f70 in call_user_function_ex
#8 0x081acb0b in php_end_ob_buffer
#9 0x081ae47c in zif_ob_end_clean
#10 0x0822fc0c in zend_do_fcall_common_helper_SPEC
#11 0x08233750 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
#12 0x0822f2a9 in execute
#13 0x081f4bc6 in zend_call_function
#14 0x081f3f70 in call_user_function_ex
#15 0x081acb0b in php_end_ob_buffer
#16 0x081ae47c in zif_ob_end_clean
#17 0x0822fc0c in zend_do_fcall_common_helper_SPEC
#18 0x08233750 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
#19 0x0822f2a9 in execute
#20 0x081f4bc6 in zend_call_function
#21 0x081f3f70 in call_user_function_ex
#22 0x081acb0b in php_end_ob_buffer
#23 0x081ae47c in zif_ob_end_clean
#24 0x0822fc0c in zend_do_fcall_common_helper_SPEC
#25 0x08233750 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
#26 0x0822f2a9 in execute
(...)
--
Test script:
---
Expected result:
ob_end_clean() and ob_end_flush() doc:
"If the function fails it generates an E_NOTICE. "
After ob termination and before calling ob callback function [set in
ob_start(func)] buffering should be terminated.
Actual result:
--
ob seems not to be terminated before calling callback function.
--
Edit this bug report at https://bugs.php.net/bug.php?id=54199&edit=1
Bug #52339 [Nab->ReO]: SPL autoloader breaks class_exists()
Edit report at https://bugs.php.net/bug.php?id=52339&edit=1
ID: 52339
Updated by: frozenf...@php.net
Reported by:dangerous dot ben at gmail dot com
Summary:SPL autoloader breaks class_exists()
-Status: Not a bug
+Status: Re-Opened
Type: Bug
Package:SPL related
Operating System: any (debian)
PHP Version:5.3.3RC2
Block user comment: N
Private report: N
New Comment:
Re-opening, as there still exists the conflict of class_exists() generating an
error when autoloading fails, which is a chicken and the egg sort of issue. If
one wants to try autoloading if the class doesn't exist, but autoloading fails,
it should be possible to recover from that failure.
My understanding of the underlying code is that it generates an error in this
case. Perhaps it should generate an exception, which can be caught an handled.
Previous Comments:
[2010-10-11 21:37:47] james at nearlysensical dot com
I 100% agree with dangerous dot ben. class_exists should return false if the
class
can't be autoloaded. Allowing it to do so would make it much easier to use an
autoloader in contexts where you're interacting with an existing codebase that
may
not be so spl_autoload friendly. Bump.
[2010-07-15 08:18:01] dangerous dot ben at gmail dot com
I beg to differ. As you say, class_exists() attempts to autoload if there
second param is true, but if autoloading fails it should simply return false as
usual rather than throw an exception. Otherwise it is rather useless.
The fact that this only occurs when there isn't another autoloader in the stack
should make it clear that this is a bug. For example, the following code does
not throw an exception:
spl_autoload_register();
spl_autoload_register(function(){});
class_exists('foo\bar');
[2010-07-15 05:11:04] ka...@php.net
You are calling class_exists() with just a class name, which leaves the second
parameter ($autoload) set to true, which then invokes SPL and throws the
exception, so no bug here
[2010-07-14 21:54:08] dangerous dot ben at gmail dot com
On further investigation, it appears that the error is meant to happen only if
spl_autoload is called directly, and not via spl_autoload_call. Unfortunately
when spl_autoload is the only autoloader in the stack it gets called directly
and spl_autoload_call doesn't get a look in.
[2010-07-14 21:31:46] dangerous dot ben at gmail dot com
Description:
Using PHP 5.3 from svn.
When SPL's default autoloader is the only loader in the stack it triggers an
error or throws an exception when it can't find a class. This means that you
get an exception when calling class_exists() for a class that doesn't exist.
This behaviour seems pointless anyway since PHP will trigger its own fatal
error if the class still doesn't exist after attempting to autoload, so the
attached patch simply removes it.
Test script:
---
spl_autoload_register();
class_exists('foo\bar');
Expected result:
No error
Actual result:
--
ben@arctor:~/src/php-5.3$ sapi/cli/php ~/code/cram/test.php
PHP Fatal error: Uncaught exception 'LogicException' with message 'Class
foo\bar could not be loaded' in /home/ben/code/cram/test.php:4
Stack trace:
#0 [internal function]: spl_autoload('foo\bar')
#1 /home/ben/code/cram/test.php(4): class_exists('foo\bar')
#2 {main}
thrown in /home/ben/code/cram/test.php on line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=52339&edit=1
Bug #60221 [Opn->Csd]: Tiger hash output byte order
Edit report at https://bugs.php.net/bug.php?id=60221&edit=1 ID: 60221 Updated by: frozenf...@php.net Reported by:chadd at fidelissys dot com Summary:Tiger hash output byte order -Status: Open +Status: Closed Type: Bug Package:hash related Operating System: Linux PHP Version:5.3.8 Assigned To:mike Block user comment: N Private report: N Previous Comments: [2012-01-27 23:12:23] frozenf...@php.net Automatic comment from SVN on behalf of frozenfire Revision: http://svn.php.net/viewvc/?view=revision&revision=322885 Log: Added changelog, indicating that the Tiger hash algorithm now uses big-endian byte ordering. Closes bug #60221. [2012-01-17 15:26:24] m...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-11-04 18:27:50] chadd at fidelissys dot com Description: The testtiger program prints its hashes with each 8-byte chunk byte-swapped (perhaps arch-dependent?). The "24f0130c63ac9332..." hash of the tiger*,3 family would be printed "3293ac630c13f024..." in MSB-first representation, e.g. as given on Wikipedia's example output. Perl's Digest::Tiger also uses the MSB-first format: http://search.cpan.org/~clintdw/Digest-Tiger-0.03/Tiger.pm#NOTE The lack of MSB-first order potentially impacts interoperability, but changing the output of "tiger192,3" would break BC with anyone who doesn't have interop problems. This bug has been observed in php 5.2.6 as well. Test script: --- Expected result: 3293ac630c13f0245f92bbb1766e16167a4e58492dde73f3 Actual result: -- 24f0130c63ac933216166e76b1bb925ff373de2d49584e7a -- Edit this bug report at https://bugs.php.net/bug.php?id=60221&edit=1
Req #60551 [Asn->Csd]: session_set_save_handler should support a core's session handler interface
Edit report at https://bugs.php.net/bug.php?id=60551&edit=1 ID: 60551 Updated by: frozenf...@php.net Reported by:wiltave at gmail dot com Summary:session_set_save_handler should support a core's session handler interface -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Session related Operating System: Any PHP Version:Irrelevant Assigned To:frozenfire Block user comment: N Private report: N Previous Comments: [2012-01-27 22:08:04] frozenf...@php.net Automatic comment from SVN on behalf of frozenfire Revision: http://svn.php.net/viewvc/?view=revision&revision=322879 Log: Documented SessionHandlerInterface. Closes bug #60551. [2012-01-04 01:18:40] ar...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. session_set_save_handler() now takes a SessionHandlerInterface, which SessionHandler implements. [2012-01-04 01:16:18] ar...@php.net Automatic comment from SVN on behalf of arpad Revision: http://svn.php.net/viewvc/?view=revision&revision=321738 Log: add SessionHandlerInterface for session_set_save_handler() - #60551 [2011-12-17 18:15:13] cataphr...@php.net Already implemented in PHP 5.4. [2011-12-17 12:16:43] wiltave at gmail dot com Description: session_set_save_handler expects callbacks to session handler's operations (open, close, etc). It would be great if this function accepts a core's session handler interface. Something like: https://bugs.php.net/bug.php?id=60551&edit=1
Req #60551 [->Asn]: session_set_save_handler should support a core's session handler interface
Edit report at https://bugs.php.net/bug.php?id=60551&edit=1 ID: 60551 Updated by: frozenf...@php.net Reported by:wiltave at gmail dot com Summary:session_set_save_handler should support a core's session handler interface -Status: To be documented +Status: Assigned Type: Feature/Change Request Package:Session related Operating System: Any PHP Version:Irrelevant -Assigned To: +Assigned To:frozenfire Block user comment: N Private report: N Previous Comments: [2012-01-04 01:18:40] ar...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. session_set_save_handler() now takes a SessionHandlerInterface, which SessionHandler implements. [2012-01-04 01:16:18] ar...@php.net Automatic comment from SVN on behalf of arpad Revision: http://svn.php.net/viewvc/?view=revision&revision=321738 Log: add SessionHandlerInterface for session_set_save_handler() - #60551 [2011-12-17 18:15:13] cataphr...@php.net Already implemented in PHP 5.4. [2011-12-17 12:16:43] wiltave at gmail dot com Description: session_set_save_handler expects callbacks to session handler's operations (open, close, etc). It would be great if this function accepts a core's session handler interface. Something like: https://bugs.php.net/bug.php?id=60551&edit=1
Req #54514 [Csd]: Get php binary path during script execution
Edit report at https://bugs.php.net/bug.php?id=54514&edit=1 ID: 54514 Updated by: frozenf...@php.net Reported by:frederic dot hardy at mageekbox dot net Summary:Get php binary path during script execution Status: Closed Type: Feature/Change Request Package:PHP options/info functions PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: Documented in http://svn.php.net/viewvc?view=revision&revision=320582 Previous Comments: [2011-12-07 10:37:36] larue...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. implement in 5.4, thanks [2011-12-07 10:32:56] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=320567 Log: Implemented FR #54514 (Get php binary path during script execution). [2011-12-07 08:57:46] patrickalla...@php.net PHP does provide a path to the binary directory: PHP_BINDIR However it is true it doesn't contain the executable itself. [2011-04-12 14:11:00] frederic dot hardy at mageekbox dot net Description: Currently, PHP does not provide any solution to retrieve PHP binary path in userland. There is a workaround with some *NIX shells like bash, which provide $_, available in $_SERVER['_'] in userland. However, it's not a reliable solution (cron task, etc.), and this hack is not available on Windows. So, a constant like PHP_BINARY (similar to PHP_VERSION and other PHP_* constants) seems to be a good solution. -- Edit this bug report at https://bugs.php.net/bug.php?id=54514&edit=1
Bug #44383 [Opn]: PHP DateTime not converted to xsd:datetime
Edit report at https://bugs.php.net/bug.php?id=44383&edit=1 ID: 44383 Updated by: frozenf...@php.net Reported by:kevin dot craft at gmail dot com Summary:PHP DateTime not converted to xsd:datetime Status: Open Type: Bug Package:SOAP related Operating System: * PHP Version:5.*, 6 (2009-08-07 Block user comment: N Private report: N New Comment: I've encountered this issue today, and it would be really wonderful to have this patch applied. Previous Comments: [2010-10-18 17:43:04] aldekein at myevil dot info It still does not work after 2.5 years in PHP 5.3.1 on Windows. Maybe this patch should be applied to official PHP branch? [2009-08-07 15:23:57] david dot zuelke at bitextender dot com Updated patch and tests: http://pastie.org/575559 [2009-06-29 08:56:29] lsm...@php.net Reopening since we now have a patch. [2009-06-29 08:28:26] david dot zuelke at bitextender dot com We've created a patch to implement this. Description (with patch and tests for download): http://article.gmane.org/gmane.comp.php.devel/57369 Patch (in case gmane doesn't work): http://pastie.org/527755 Tests (in case gmane doesn't work): http://pastie.org/527762 [2008-06-30 12:00:56] r dot janssen at keensystems dot eu I am, too, looking for a solution for this problem. I can specify parameters as dateTime type but when generating the WSDL the generation stops and does nothing. 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 https://bugs.php.net/bug.php?id=44383 -- Edit this bug report at https://bugs.php.net/bug.php?id=44383&edit=1
Doc->Req #54405 [Opn]: FETCH_GROUP always operates on first column
Edit report at https://bugs.php.net/bug.php?id=54405&edit=1 ID: 54405 Updated by: frozenf...@php.net Reported by:php at bucksvsbytes dot com Summary:FETCH_GROUP always operates on first column Status: Open -Type: Documentation Problem +Type: Feature/Change Request -Package:Documentation problem +Package:PDO related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This seems like more of a bug/feature request, since the current behavior is near useless. After (if) it's been patched, please change this bug to a documentation problem bug type, so the change and new behavior can be documented. Previous Comments: [2011-05-02 01:29:30] jinmoku at hotmail dot com Or maybe add a fetch.column for FETCH_GROUP (see path) [2011-03-28 04:51:11] php at bucksvsbytes dot com Description: --- >From manual page: http://www.php.net/pdostatement.fetchall#Parameters --- The following statement is misleading/incorrect, "To return an associative array grouped by the values of a specified column, bitwise-OR PDO::FETCH_COLUMN with PDO::FETCH_GROUP." It's apparent that FETCH_GROUP only groups on the first query column, so "a specified" should be replaced with "the first". -- Edit this bug report at https://bugs.php.net/bug.php?id=54405&edit=1
Doc->Req #55822 [Opn]: elseif/else if opcode difference
Edit report at https://bugs.php.net/bug.php?id=55822&edit=1 ID: 55822 Updated by: frozenf...@php.net Reported by:jhansche at myyearbook dot com Summary:elseif/else if opcode difference Status: Open -Type: Documentation Problem +Type: Feature/Change Request -Package:Documentation problem +Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: @derick: I agree that it would probably be sensible for PHP to conjoin else if into elseif, where it sees that opcode combination. I'll change the bug to that. Previous Comments: [2011-10-09 09:59:21] der...@php.net @frozenfire: No need to open a bug (he already did that AFAIK), because it's not something in Xdebug that I can do anything about (as the opcodes are generated by PHP). It doesn't belong in PHP's docs though, but perhaps we can see whether we can change PHP itself to make this look similar. [2011-10-08 21:35:36] frozenf...@php.net I feel that discussion of the opcode is beyond the scope of that document. It's a very esoteric distinction, which would only serve to confuse, rather than to educate. It would probably be a better idea to document this in XDebug or PHPUnit's manual, rather than PHP's. For the purposes of the execution of the code, this distinction is irrelevant. Though, better yet, it might be worth opening a bug for XDebug, indicating that this trivial opcode distinction is impairing the ability to get proper code coverage. [2011-09-30 16:42:57] jhansche at myyearbook dot com Description: --- >From manual page: http://www.php.net/control-structures.elseif --- It is worth explaining the difference in opcode generation using "elseif" vs "else if" -- or at least the effect of using one over the other. Specifically, I'm referring to using PHPUnit with XDebug, in order to get code coverage for some code. What I've noticed is that using "else if", even if you fully test that branch, no code coverage is produced for that condition line (the code coverage report just skips over the "else if .." line, leaving one line unexecuted, while everything else is green). Replacing that line with "elseif" instead, produces full green code coverage! See the test script below, and the output from using vld (http://pecl.php.net/package/vld) to show the difference in opcode generation, wherein having the space between "else" and "if" causes the opcode to report the wrong line number, and therefore something like xdebug, which tracks what lines get executed, is unable to track the fact that the line was executed, and there is no code coverage. The difference between "elseif" and "else if" should not cause unit testing code coverage reports to change behavior. The only way to get proper code coverage with this bug is to force the developer to use "elseif". Test script and results can also be seen at: https://php.privatepaste.com/f468504857 Test script: --- space.php: nospace.php: space.vld $ php -dvld.active=1 nospace.php >nospace.vld $ diff -uN space.vld nospace.vld -- Edit this bug report at https://bugs.php.net/bug.php?id=55822&edit=1
#47323 [NEW]: strotime warnings in make install
From: frozenfire at thefrozenfire dot com Operating system: Ubuntu 8.10 2.6.27-11-generic PHP version: 5.3.0beta1 PHP Bug Type: Compile Warning Bug description: strotime warnings in make install Description: I've configured a vanilla install of PHP 5.3 Beta 1, using ./configure --prefix=/usr/local/php-5.3 --program-suffix=53 After configuring (And resolving some missing dependencies), I did a make, and then a make test (Results submitted). Next, I did a make install, which produced: Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PST/-8.0/no DST' instead in phar:///home/myuser/php-5.3.0beta1/pear/install-pear-nozlib.phar/PEAR/Validate.php on line 489 About a dozen times during "Installing PEAR environment: /usr/local/php-5.3/lib/php/" I don't know if it's related, but the interactive mode in PHP doesn't work (php53 -a). It prints out "Interactive mode enabled" and then allows input, but doesn't process it in any way, including "exit." Reproduce code: --- sudo ./configure --prefix=/usr/local/php-5.3 --program-suffix=53 sudo make sudo make test sudo make install Expected result: For the make install, I expected none of the warning messages. Actual result: -- Full make install output: http://pastebin.ca/1328662 -- Edit bug report at http://bugs.php.net/?id=47323&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47323&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47323&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47323&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47323&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47323&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47323&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47323&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47323&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47323&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47323&r=support Expected behavior: http://bugs.php.net/fix.php?id=47323&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47323&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47323&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47323&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47323&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47323&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47323&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47323&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47323&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47323&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47323&r=mysqlcfg
#45661 [Opn]: Error in mktime when omitting day
ID: 45661
User updated by: frozenfire at thefrozenfire dot com
Reported By: frozenfire at thefrozenfire dot com
Status: Open
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5.2.6
New Comment:
// Working code. Produces intuitive output.
// Original bug report used 0 as 5th param
for($i=1; $i<13; $i++) echo date('M', mktime(0, 0, 0, $i, 1))."\n";
Previous Comments:
[2008-07-31 00:47:56] frozenfire at thefrozenfire dot com
Description:
There is a bug in mktime, where omission of the day parameter causes
some issues.
Most notably, when attempting to iterate through months. See the
reproduction code for a better explanation.
Reproduce code:
---
// Bugged code. Produces "Mar" twice.
for($i=1; $i<13; $i++) echo date('M', mktime(0, 0, 0, $i))."\n";
// Working code. Produces intuitive output.
for($i=1; $i<13; $i++) echo date('M', mktime(0, 0, 0, $i, 0))."\n";
Expected result:
Jan
Feb
Mar
Apr
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Actual result:
--
Jan
Mar
Mar
Apr
Jun
Jul
Aug
Sep
Oct
Nov
Dec
--
Edit this bug report at http://bugs.php.net/?id=45661&edit=1
#45661 [NEW]: Error in mktime when omitting day
From: frozenfire at thefrozenfire dot com
Operating system: Windows XP SP2
PHP version: 5.2.6
PHP Bug Type: Date/time related
Bug description: Error in mktime when omitting day
Description:
There is a bug in mktime, where omission of the day parameter causes some
issues.
Most notably, when attempting to iterate through months. See the
reproduction code for a better explanation.
Reproduce code:
---
// Bugged code. Produces "Mar" twice.
for($i=1; $i<13; $i++) echo date('M', mktime(0, 0, 0, $i))."\n";
// Working code. Produces intuitive output.
for($i=1; $i<13; $i++) echo date('M', mktime(0, 0, 0, $i, 0))."\n";
Expected result:
Jan
Feb
Mar
Apr
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Actual result:
--
Jan
Mar
Mar
Apr
Jun
Jul
Aug
Sep
Oct
Nov
Dec
--
Edit bug report at http://bugs.php.net/?id=45661&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45661&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45661&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45661&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45661&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45661&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45661&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45661&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45661&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45661&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45661&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45661&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45661&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45661&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45661&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45661&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45661&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45661&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45661&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45661&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45661&r=mysqlcfg
