#46730 [NEW]: json_decode and 32Bit Maschines
From: info at marcel-schlesinger dot de
Operating system: ALL
PHP version: 5.2.6
PHP Bug Type: Unknown/Other Function
Bug description: json_decode and 32Bit Maschines
Description:
Using json_decode with numbers higher then 2147483647 on a 32Bit maschine
is still wrong! E.g. 5095334700020 has to be converted into a float (a
string would be also okay), but not into an integer!
Reproduce code:
---
?php
$json = '{number:5095334700020}';
var_dump(json_decode($json));
?
Expected result:
object(stdClass)#1 (1) {
[number]=
float(5095334700020)
}
it could also be:
object(stdClass)#1 (1) {
[number]=
string(13) 5095334700020
}
Actual result:
--
object(stdClass)#1 (1) {
[number]=
int(2147483647)
}
--
Edit bug report at http://bugs.php.net/?id=46730edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46730r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46730r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46730r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46730r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46730r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46730r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46730r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46730r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46730r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46730r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46730r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46730r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46730r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46730r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46730r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46730r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46730r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46730r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46730r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46730r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46730r=mysqlcfg
#46730 [Opn]: json_decode and 32Bit Maschines
ID: 46730
User updated by: info at marcel-schlesinger dot de
Reported By: info at marcel-schlesinger dot de
Status: Open
-Bug Type: Unknown/Other Function
+Bug Type: JSON related
Operating System: ALL
PHP Version: 5.2.6
New Comment:
Updated category
Previous Comments:
[2008-12-02 12:53:32] info at marcel-schlesinger dot de
Description:
Using json_decode with numbers higher then 2147483647 on a 32Bit
maschine is still wrong! E.g. 5095334700020 has to be converted into a
float (a string would be also okay), but not into an integer!
Reproduce code:
---
?php
$json = '{number:5095334700020}';
var_dump(json_decode($json));
?
Expected result:
object(stdClass)#1 (1) {
[number]=
float(5095334700020)
}
it could also be:
object(stdClass)#1 (1) {
[number]=
string(13) 5095334700020
}
Actual result:
--
object(stdClass)#1 (1) {
[number]=
int(2147483647)
}
--
Edit this bug report at http://bugs.php.net/?id=46730edit=1
#46729 [NEW]: xslt_base_dir parameter doesn't work
From: gpl at ircf dot fr
Operating system: Linux Ubuntu 8.10
PHP version: 5.2.6
PHP Bug Type: XSLT related
Bug description: xslt_base_dir parameter doesn't work
Description:
Base path cannot be changed by setting the parameter xslt_base_dir in the
xslt processor. This bug was also reported here :
http://bugs.php.net/bug.php?id=43454edit=3
Reproduce code:
---
?php
// First, load a XSL stylesheet
$xslDom = DomDocument::loadXML('xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;xsl:include
href=foo//xsl:stylesheet');
// Then initialize the XSLTProcessor
$xsltProcessor = new xsltprocessor();
// Set the xslt_base_dir
$xsltProcessor-setParameter('','xslt_base_dir','base');
// Import the stylesheet in the processor
$xsltProcessor-importStylesheet($xslDom);
?
Expected result:
This program should raise the following warning : Failed to load external
entity .../base/foo
Actual result:
--
The program raises the warning : Failed to load external entity .../foo
--
Edit bug report at http://bugs.php.net/?id=46729edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46729r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46729r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46729r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46729r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46729r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46729r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46729r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46729r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46729r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46729r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46729r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46729r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46729r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46729r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46729r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46729r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46729r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46729r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46729r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46729r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46729r=mysqlcfg
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994 Comment by: brem at martinbreton dot com Reported By: dbarrett at vistaprint dot com Status: Assigned Bug Type: Program Execution Operating System: win32 only - 2003 Server, 64-bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: If that's any help, I'm using a COM object as a workaround for this bug, and while it makes this bug appear less frequently, it still happens, randomly, from time to time. Here's what i did as a workaround using the exec() function call: $WshShell = new COM(WScript.Shell); $OutputFile = C:\\Temp\\output.txt; $Command = cmd /C MyApp.exe $OutputFile; $WshShell-Run( $Command, 0, true ); file_get_contents( $OutputFile ) ); unlink( $OutputFile ); Previous Comments: [2008-11-18 08:46:34] bernd dot ebert at gmx dot net Same Problem here with an commandline-script calling other php-commandline-scripts. It seems to happen more frequently if you have a lot of exec-calls. [2008-08-19 02:58:37] jkflash at gmail dot com Sorry, I take that last comment back, it still hangs annoyingly intermittently with shell_exec as well. It's a killer :( [2008-08-13 01:08:19] jkflash at gmail dot com PS: shell_exec() DOES seem to work without hanging on my setup, but none of the others. [2008-08-12 23:50:58] jkflash at gmail dot com I am experiencing this same problem with PHP 5.2.1 running on IIS as an ISAPI module on Windows Server 2003 R2 SP2. Intermitently (a handful of times in a hundred) a process started with exec() will appear to complete ok but remain running in a zombie state. The IIS worker process that created the process will not respond to any further requests. I need to either open a new client browser or kill the worker process. I get the same result with system, passthru, p_open and proc_open. [2008-07-29 15:03:40] nobody at dontsendmespam dot com i can reproduce this problem on a debian server with apache2 and php5.2.6 running as fcgi 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/44994 -- Edit this bug report at http://bugs.php.net/?id=44994edit=1
#46730 [Opn-Bgs]: json_decode and 32Bit Maschines
ID: 46730
Updated by: [EMAIL PROTECTED]
Reported By: info at marcel-schlesinger dot de
-Status: Open
+Status: Bogus
Bug Type: JSON related
Operating System: ALL
PHP Version: 5.2.6
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.
Can't reproduce -- should be fixed since 5.2.4... Feel free to reopen
if you're actually using 5.2.6 and seeing this. :-)
Previous Comments:
[2008-12-02 13:01:36] info at marcel-schlesinger dot de
Updated category
[2008-12-02 12:53:32] info at marcel-schlesinger dot de
Description:
Using json_decode with numbers higher then 2147483647 on a 32Bit
maschine is still wrong! E.g. 5095334700020 has to be converted into a
float (a string would be also okay), but not into an integer!
Reproduce code:
---
?php
$json = '{number:5095334700020}';
var_dump(json_decode($json));
?
Expected result:
object(stdClass)#1 (1) {
[number]=
float(5095334700020)
}
it could also be:
object(stdClass)#1 (1) {
[number]=
string(13) 5095334700020
}
Actual result:
--
object(stdClass)#1 (1) {
[number]=
int(2147483647)
}
--
Edit this bug report at http://bugs.php.net/?id=46730edit=1
#46728 [NEW]: PDO(OCI)::fetchAll with stream (CLOB) : resource contains always same value
From: berlioz at nicematin dot fr
Operating system: Linux (All ?)
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: PDO(OCI)::fetchAll with stream (CLOB) : resource contains
always same value
Description:
in PDO_OCI when you retrieve records from a table with a CLOB field using
fetchAll(), fetchAll() returns different resource ids but they all contain
the same datas from the last record of the set. Other fields are ok.
if you loop with fetch it works fine.
Reproduce code:
---
$conn = new PDO(oci:dbname=.$tns,$db_username,$db_password);
$stmt=$conn-query('select * from my_table_with_clob');
$records=$stmt-fetchAll(PDO::FETCH_ASSOC);
print_r($records);
foreach($records as $record)
{
echo my_clob=.stream_get_contents($record['MY_CLOB']).\n;
}
Expected result:
my_clob=Data from record 0
my_clob=Data from record 1
my_clob=Data from record 2
my_clob=Data from record 3
my_clob=Data from record 4
Actual result:
--
my_clob=Data from record 4
my_clob=Data from record 4
my_clob=Data from record 4
my_clob=Data from record 4
my_clob=Data from record 4
--
Edit bug report at http://bugs.php.net/?id=46728edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46728r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46728r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46728r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46728r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46728r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46728r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46728r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46728r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46728r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46728r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46728r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46728r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46728r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46728r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46728r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46728r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46728r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46728r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46728r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46728r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46728r=mysqlcfg
#46731 [NEW]: Imap FT_UID handling problem
From: zoe dot slattery at googlemail dot com Operating system: Linux PHP version: 5.3CVS-2008-12-02 (snap) PHP Bug Type: Scripting Engine problem Bug description: Imap FT_UID handling problem Description: In imap_fetch_overview() the FT_UID parameter is treated as a bitmap. This means that giving it completely invalid parameters for FT_UID does not cause an error. Suggested fix to imap_fetch_overview() is here: http://pastebin.com/m750e3ed2 Reproduce code: --- To run this you would need the imap_include.inc file that is in ~ext/imap/tests. http://pastebin.com/m4da53733 Expected result: From this code I'd expect two successful fetches followed by two failures. Actual result: -- Four successful fetches, PHP_INT_MAX and PHP_INT_MAX-1 are interpreted as 1 and 0 respectively. -- Edit bug report at http://bugs.php.net/?id=46731edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46731r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46731r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46731r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46731r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46731r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46731r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46731r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46731r=needscript Try newer version: http://bugs.php.net/fix.php?id=46731r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46731r=support Expected behavior: http://bugs.php.net/fix.php?id=46731r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46731r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46731r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46731r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46731r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46731r=dst IIS Stability: http://bugs.php.net/fix.php?id=46731r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46731r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46731r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46731r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46731r=mysqlcfg
#46732 [Opn-Asn]: mktime.year description is wrong
ID: 46732 Updated by: [EMAIL PROTECTED] Reported By: dynkin at gmail dot com -Status: Open +Status: Assigned -Bug Type: Documentation problem +Bug Type: Date/time related Operating System: linux -PHP Version: Irrelevant +PHP Version: PHP 5 -Assigned To: +Assigned To: derick New Comment: This is a bug in the code though Previous Comments: [2008-12-02 16:27:08] dynkin at gmail dot com Description: Documentation of mktime's year parameter states that The number of the year, may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-100 to 1970-2000. But this part, `70-100 to 1970-2000`, is not precise. As in the implementation in ext/date/php_date.c::php_mktime, the doc should read: 70-110 to 1970-2010, instead of, 70-100 to 1970-2000. Reproduce code: --- echo date(Y-m-d, mktime(0,0,0,1,1,110)); Actual result: -- 2010-01-01 -- Edit this bug report at http://bugs.php.net/?id=46732edit=1
#46732 [Asn-Csd]: mktime.year description is wrong
ID: 46732 Updated by: [EMAIL PROTECTED] Reported By: dynkin at gmail dot com -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: linux PHP Version: PHP 5 Assigned To: derick New Comment: This bug has been fixed in CVS. 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. Previous Comments: [2008-12-02 17:06:24] [EMAIL PROTECTED] This is a bug in the code though [2008-12-02 16:27:08] dynkin at gmail dot com Description: Documentation of mktime's year parameter states that The number of the year, may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-100 to 1970-2000. But this part, `70-100 to 1970-2000`, is not precise. As in the implementation in ext/date/php_date.c::php_mktime, the doc should read: 70-110 to 1970-2010, instead of, 70-100 to 1970-2000. Reproduce code: --- echo date(Y-m-d, mktime(0,0,0,1,1,110)); Actual result: -- 2010-01-01 -- Edit this bug report at http://bugs.php.net/?id=46732edit=1
#45989 [Opn]: json_decode() passes through certain invalid JSON strings
ID: 45989
User updated by: steven at acko dot net
Reported By: steven at acko dot net
Status: Open
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
New Comment:
till said:
but it's supposed to return the string as is -- in case it's a literal
type, but why does it in some cases return null then?
What argument is there for having (some) unparseable sequences returned
as is? If json_decode() returns a string, then that should mean that
the
input was a valid JSON encoding of that string, no?
The only literal types JSON allows are numbers and the pre-defined
constants 'true' 'false' and 'null'. Strings must be quote-delimited.
The fact that you can switch between 'return NULL' and 'return the
argument as-is' just by adding/removing a leading space is a pretty big
sign that something is wrong here. To be honest, it seems a bit silly
that this is even an argument.
Previous Comments:
[2008-12-01 17:16:06] [EMAIL PROTECTED]
Just to add to this:
I know that the function is not supposed to be a JSON validator, but
it's supposed to return the string as is -- in case it's a literal type,
but why does it in some cases return null then?
For example:
$bad_json = { 'bar': 'baz' };
json_decode($bad_json); // null
I know this is probably an edge-case but $bad_json could be my own
/valid/ string -- not valid JSON. Because a string could look like
anything. Point well taken, I'm passing in a pretty /funky/ looking
string. But instead of NULL, json_decode should return the string
as-is.
That is, according to the documentation, a bug. ;-)
Lots of people also seemed to rely on json_decode as a json validator.
Which is -- once you understand the subtle differences -- not the case.
The case should be made for either one though.
[2008-11-17 15:23:35] [EMAIL PROTECTED]
@Iliaa:
Could this bug be re-evaluated or a more detailed explaination as of
why the docs sometimes note that NULL is returned on invalid json, and
why sometimes json_decode() returns the string instead?
If the function returns whatever then the docs should be updated to
tell the user to not rely on what is returned by json_decode at all.
;-)
I double-checked some of Steve's examples on jsonlint.com (which is in
most docs cited as the reference validator for json data) and they all
show up as invalid.
I also build the most recent 5.2.7 snapshot:
./configure --disable-all --enable-json
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php
string(14) 'invalid json'
string(12) invalid json
string(2) {
string(2) [
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: (none)
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)
[EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m
[PHP Modules]
date
json
Reflection
standard
[Zend Modules]
I'm gonna write a test and send it to QA too.
[2008-09-10 01:14:23] steven at acko dot net
Please clarify the bogus classification.
The following each returns NULL, as expected:
var_dump(json_decode('[')); // unmatched bracket
var_dump(json_decode('{')); // unmatched brace
var_dump(json_decode('{}}')); // unmatched brace
var_dump(json_decode('{error error}')); // invalid object key/value
notation
var_dump(json_decode('[\]')); // unclosed string
var_dump(json_decode('[ \x ]')); // invalid escape code
Yet the following each returns the literal argument as a string:
var_dump(json_decode(' ['));
var_dump(json_decode(' {'));
var_dump(json_decode(' {}}'));
var_dump(json_decode(' {error error}'));
var_dump(json_decode('\'));
var_dump(json_decode(' \x '));
Please examine the examples closely: they are all meaningless, invalid
JSON. Even under the
most widely stretched definition of JSON, the above is not JSON encoded
data. Yet
json_decode() arbitarily returns /some of it/ as a string... and in a
way that looks
suspiciously like a bad parser implementation.
If this was merely a case of json_decode() returning /all/ invalid json
as is, then it could
be classified as an implementation quirk. But because of how
inconsistent it is now, you
can't say that it is by design or following any kind of spec.
E.g. how would you currently see if json_decode() succeeded or not?
[2008-09-10 00:38:09] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
#41631 [Com]: default_socket_timeout does not work with SSL
ID: 41631 Comment by: nvora at yahoo-inc dot com Reported By: david at acz dot org Status: No Feedback Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.6 Assigned To: pajoye New Comment: we are running into the same issue. where can i take a look at the patch? is the fix already checked in to cvs? Previous Comments: [2008-11-10 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-11-02 12:46:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-10-03 13:37:01] jose dot rodriguez at exec dot cl reproduced on PHP 5.2.6 @ Windows XP [2008-10-02 08:07:58] cunami at gmail dot com Bug also reproducible on PHP 5.2.4 (2ubuntu5.3). [2008-02-25 21:03:17] konstantin dot ryabitsev at mcgill dot ca This is still happening on 5.2.5, and is really annoying when a soap server you are connecting to accepts the connection and then hangs. Effectively, this quickly results in a denial of service for the entire site, as the end-result is hung HTTP processes. Please consider this for a high-priority fix. 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/41631 -- Edit this bug report at http://bugs.php.net/?id=41631edit=1
#46731 [Opn-Csd]: Imap FT_UID handling problem
ID: 46731 Updated by: [EMAIL PROTECTED] Reported By: zoe dot slattery at googlemail dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3CVS-2008-12-02 (snap) New Comment: This bug has been fixed in CVS. 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. Previous Comments: [2008-12-02 16:04:17] zoe dot slattery at googlemail dot com Description: In imap_fetch_overview() the FT_UID parameter is treated as a bitmap. This means that giving it completely invalid parameters for FT_UID does not cause an error. Suggested fix to imap_fetch_overview() is here: http://pastebin.com/m750e3ed2 Reproduce code: --- To run this you would need the imap_include.inc file that is in ~ext/imap/tests. http://pastebin.com/m4da53733 Expected result: From this code I'd expect two successful fetches followed by two failures. Actual result: -- Four successful fetches, PHP_INT_MAX and PHP_INT_MAX-1 are interpreted as 1 and 0 respectively. -- Edit this bug report at http://bugs.php.net/?id=46731edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: yell at yllow1 dot pl Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: After my debugging - it seems script runs to the end (trigger_error even in last line works). Adding one print(null); in random place of script did help me! But I had this problem for 3 places, it help only for one. And now is the best :) Huge block of print(null);print(null). is enough in my case :) I only have hope - my customer will not look into source ;) yellow1pl Previous Comments: [2008-11-20 09:06:01] john dot glazebrook at guava dot com The more comments the more this sounds like a race condition. Looks like it would be almost impossible to bug hunt. Have you tried the 6 version? Maybe this has been fixed? John [2008-11-19 16:46:12] rpeters at icomproductions dot ca We are experiencing multiple zend_mm_heap corrupted errors daily on our production server during peak load. During off-peak periods, all scripts work as expected. PHP 5.2.2 RedHat Linux 2.6.9-78.0.5.ELsmp Why is this set to No Feedback when there's a debug dump provided? [2008-10-20 08:07:39] moo at moo dot com hello? [2008-10-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-10-06 15:52:07] john dot glazebrook at guava dot co dot uk Re: My last post: I disabled as much stuff as I could before running the bad page. John 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/40479 -- Edit this bug report at http://bugs.php.net/?id=40479edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: yell at yellow1 dot pl Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: On the other hand now i had a lot of [notice] child pid 29716 exit signal Segmentation fault (11) in log, but at least it sends output befor exit,so I can live with it ;) Previous Comments: [2008-12-03 01:52:51] yell at yllow1 dot pl After my debugging - it seems script runs to the end (trigger_error even in last line works). Adding one print(null); in random place of script did help me! But I had this problem for 3 places, it help only for one. And now is the best :) Huge block of print(null);print(null). is enough in my case :) I only have hope - my customer will not look into source ;) yellow1pl [2008-11-20 09:06:01] john dot glazebrook at guava dot com The more comments the more this sounds like a race condition. Looks like it would be almost impossible to bug hunt. Have you tried the 6 version? Maybe this has been fixed? John [2008-11-19 16:46:12] rpeters at icomproductions dot ca We are experiencing multiple zend_mm_heap corrupted errors daily on our production server during peak load. During off-peak periods, all scripts work as expected. PHP 5.2.2 RedHat Linux 2.6.9-78.0.5.ELsmp Why is this set to No Feedback when there's a debug dump provided? [2008-10-20 08:07:39] moo at moo dot com hello? [2008-10-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/40479 -- Edit this bug report at http://bugs.php.net/?id=40479edit=1
#43901 [Com]: PHP needs new function to expand strings
ID: 43901
Comment by: cvolny at gmail dot com
Reported By: t03 at springtimesoftware dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.5
New Comment:
I wrote two functions to display ways of accomplishing this already
(although a built-in function would be nice).
This function is very restrictive and requires you to pass a hash
(name=value) as $vars. I prefer and use this function to build page
layout with predefined variables to be placed in a template file (I put
stuff like div id=content$content/div where a page's specific
content should go). I consider this a safer way to string expand as you
are explicitly limiting what can be expanded. Some improvements can be
done to it to handle arrays, but I haven't had a need for it yet.
function stringExpand($subject, array $vars) {
// loop over $vars map
foreach ($vars as $name = $value) {
// use preg_replace to match ${`$name`} or $`$name`
$subject = preg_replace(sprintf('/\$\{?%s\}?/', $name), $value,
$subject);
}
// return variable expanded string
return $subject;
}
This second function accomplishes the same task only using eval() and
variables in the current symbol table (with the help of extract()). I
opted to use heredoc with optionally a randomly generated delimiter.
This allows access to all variables available to the function (static
members, globals, $vars, etc) so it could potentially allow access to
preferably private data. I won't even go into the security implications
of using eval() to accomplish this, it's probably better to use
something like the above. here it is:
function stringExpandDangerous($subject, array $vars = array(), $random
= true) {
// extract $vars into current symbol table
extract($vars);
$delim;
// if requested to be random (default), generate delim, otherwise use
predefined (trivially faster)
if ($random)
$delim = '___' . chr(mt_rand(65,90)) . chr(mt_rand(65,90)) .
chr(mt_rand(65,90)) . chr(mt_rand(65,90)) . chr(mt_rand(65,90)) .
'___';
else
$delim = '__ASDFZXCV1324ZXCV__'; // button mashing...
// built the eval code
$statement = return $delim\n\n . $subject . \n$delim;\n;
// execute statement, saving output to $result variable
$result = eval($statement);
// if eval() returned FALSE, throw a custom exception
if ($result === false)
throw new EvalException($statement);
// return variable expanded string
return $result;
}
As you can see you can easily (and dangerously) accomplish this task
using eval() or you can cautiously accomplish it using a variant of
regex. I would recommend limiting the access of your string expansion
script as well as avoiding eval(), you can capture variable names
values easily using compact(). I wouldnt allow your script access to
$GLOBALS like the above comment, you might not want that data as
accessible as youre making it.
Previous Comments:
[2008-01-24 20:02:40] t03 at springtimesoftware dot com
In case anyone else reads this and needs a workaround, here is function
to expand any embedded variables of the form $name found inside a
given string. Note: this uses the global scope, even if called from
inside a function.
// Expand global variables if found in a string
// ExpandVars ver=1/24/08
function ReplaceVarCallback($M)
{
if (!isset($GLOBALS[$M[1]]))
die(Variable [EMAIL PROTECTED] is undefined.);
return $GLOBALS[$M[1]];
} // ReplaceVarCallback
function ExpandVars($Str)
{
for (;;)
{
$Res=preg_replace_callback('#\$([A-Za-z_][A-Za-z0-9_]*)#',
ReplaceVarCallback,$Str);
if ($Res==$Str)
break;
$Str=$Res;
}
return $Str;
} // ExpandVars
[2008-01-21 01:56:50] t03 at springtimesoftware dot com
Description:
(Note: This feature request is similar to some existing ones, but
provides much clearer explanation, motivation, and details. I hope it
will be considered on its own and that this proposal gets elevated to
the PHP design team for serious consideration.)
In PHP, string literals that are specified using quotation marks () or
HEREDOC syntax are implicitly expanded in several ways, including
translation of backslash-escaped characters and substitution of the
actual values of variables, as indicated by leading left brace or dollar
signs.
There are many common programming situations
