Bug #54918 [Opn]: browscap issues
Edit report at http://bugs.php.net/bug.php?id=54918edit=1 ID: 54918 Updated by: cataphr...@php.net Reported by:neweracracker at gmail dot com Summary:browscap issues Status: Open Type: Bug Package:Reproducible crash Operating System: Windows 7 PHP Version:5.3SVN-2011-05-24 (snap) -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N New Comment: I'm assigning to me; it's likely related to the changes I've made recently. Previous Comments: [2011-05-25 01:35:26] neweracracker at gmail dot com Changing status to open [2011-05-25 01:26:00] neweracracker at gmail dot com I tried reproducing this in CLI and it didn't reproduced. Trying with CGI sapi did cause a crash. (using revision 311390) Thread 0 - System ID 5276 Entry point php_cgi!mainCRTStartup Create time 25-05-2011 00:18:58 Time spent in user mode 0 Days 0:0:0.31 Time spent in kernel mode 0 Days 0:0:0.78 FunctionArg 1 Arg 2 Arg 3 Source php5ts!zm_deactivate_browscap+1100010013 01372998 php5ts!zm_deactivate_basic+15e 0001001301372998 php5ts!module_registry_cleanup+1b 00ce41a001372998 01372998 php5ts!zend_hash_reverse_apply+3f 5f97d5805f3f66c0 01372998 php5ts!zend_deactivate_modules+61 013729980005 01372998 php5ts!php_request_shutdown+235 013ca4c80001 php_cgi!main+e8900050137287801371cd8 php_cgi!memset+160 7ffd8000008df9b477c7b459 kernel32!BaseThreadInitThunk+e 7ffd8000779f3b4d ntdll!__RtlUserThreadStart+70 013c6a7a7ffd8000 ntdll!_RtlUserThreadStart+1b013c6a7a7ffd8000 PHP5TS!ZM_DEACTIVATE_BROWSCAP+11In php-cgi__PID__3272__Date__05_25_2011__Time_12_21_19AM__599__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zm_deactivate_browscap+11 in J:\server\bin\php53\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x080049a4 on thread 0 [2011-05-25 00:09:48] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2011-05-24 17:01:55] neweracracker at gmail dot com Description: Hello, I've downloaded PHP 5.3 revision 311383 TS from windows.php.net/snapshots/ I have managed to reproduce a crash using nginx and php fcgi related to browscap. It works flawless prior to this commit svn.php.net/viewvc?view=revisionrevision=310691 but new versions crash How to reproduce. 1. Use php.ini-production as your php.ini 2. Uncomment browscap in php.ini 3. Set it to a valid ini file ( for example: lite_php_browscap.ini from browsers.garykeith.com/downloads.asp ) 4. Run the test script 5. Enjoy the crash ;) Please reproduce and fix. Thank you. Test script: --- ?php phpinfo(); ? -- Edit this bug report at http://bugs.php.net/bug.php?id=54918edit=1
Bug #30210 [Com]: Destructor resetting working-directory
Edit report at http://bugs.php.net/bug.php?id=30210edit=1
ID: 30210
Comment by: olafurw at gmail dot com
Reported by:m dot leuffen at i-line dot net
Summary:Destructor resetting working-directory
Status: Bogus
Type: Bug
Package:Directory function related
Operating System: Linux
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
This has been fixed in newer versions of PHP. Works in 5.2.6 and 5.3.5
at least.
Previous Comments:
[2011-05-24 13:31:37] pinaki17 at gmail dot com
I know this is a old thread but the issue still exists. How can this
possibly be not a bug? The current working directory is where all the
include file dependencies are related to. How would you justify
resetting it? Also what logic goes behind it? As i understand, i can set
the working directory again in the destructor and write the code and all
these objects will be gc'ed once the page dies, so why have the reset
happen before the destructor?
[2004-09-23 20:27:49] he...@php.net
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
The destructor is called during shutdown. If you require certain
behavior the unset() your object before the script terminates.
[2004-09-23 16:31:11] m dot leuffen at i-line dot net
Description:
Hi.
In __destruct() function the working-directory is default set to root
('/').
Bye,
Matthias
Reproduce code:
---
class Test {
public function __construct() {
echo Constructor: .getcwd();
}
public function __destruct() {
echo \nDestructor: .getcwd();
}
}
$obj = new Test();
Expected result:
Constructor: /home/xyz/dir
Destructor: /home/xyz/dir
Actual result:
--
Constructor: /home/xyz/dir
Destructor: /
--
Edit this bug report at http://bugs.php.net/bug.php?id=30210edit=1
[PHP-BUG] Bug #54924 [NEW]: assert.active is not being reset upon request shutdown
From: Operating system: Linux PHP version: 5.3.6 Package: Unknown/Other Function Bug Type: Bug Bug description:assert.active is not being reset upon request shutdown Description: The assert related functions are saving their state in a global structure. The problem is that the assert state is not being reset in the RSHUTDOWN function and thus the assert state of the last request will be used for the next request. Example: If assert is active by default (php.ini assert.active) and you set it to false via assert_options this works fine. However on the next request the default will be that assert is not active. The fix is to add ASSERTG(active)=INI_INT(assert.active); to asserts RSHUTDOWN function. I am using the FastCGI SAPI. Test script: --- var_dump(assert_options(ASSERT_ACTIVE)); assert(false); var_dump(assert_options(ASSERT_ACTIVE,1)); assert(false); var_dump(assert_options(ASSERT_ACTIVE,0)); assert(false); Expected result: int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 3 int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 5 int(1) Actual result: -- First request: int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 3 int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 5 int(1) Second request (make sure you hit the same pid): int(0) int(0) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 5 int(1) -- Edit bug report at http://bugs.php.net/bug.php?id=54924edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54924r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54924r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54924r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54924r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54924r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54924r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54924r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54924r=needscript Try newer version: http://bugs.php.net/fix.php?id=54924r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54924r=support Expected behavior: http://bugs.php.net/fix.php?id=54924r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54924r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54924r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54924r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54924r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54924r=dst IIS Stability: http://bugs.php.net/fix.php?id=54924r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54924r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54924r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54924r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54924r=mysqlcfg
Bug #54347 [Com]: reflection_extension does not lowercase module function name
Edit report at http://bugs.php.net/bug.php?id=54347edit=1
ID: 54347
Comment by: neuhauser+bugs dot php dot net at sigpipe dot cz
Reported by:laruence at yahoo dot com dot cn
Summary:reflection_extension does not lowercase module
function name
Status: Open
Type: Bug
Package:Reflection related
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
i'm wrapping a third-party C library that exposes functions named with
camel case. i need to keep the function names. this bug makes the
implementation more verbose, and the names returned from
ReflectionExtension are harder to read.
this bug (or limitation) should be pointed out in
http://www.php.net/manual/en/internals2.funcs.php
Previous Comments:
[2011-03-22 16:01:31] cataphr...@php.net
This should still probably be fixed, but the functions should be
declared with lowercase names. If you search for PHP_FE in lxr.php.net,
you'll notice this is always the case.
In any case, since zend_register_functions does a lowercasing of the
function names in the module list, the reflection ext should do it too.
But for forward compatibility (in the future we may want to reduce the
points where names are lowercased), it would be best if the extension
follows the convention.
[2011-03-22 13:36:18] laruence at yahoo dot com dot cn
Description:
in
static void _extension_string(string *str, zend_module_entry *module,
char *indent TSRMLS_DC)
in php_reflection.c
when reflect extension functions , the codes:
while (func-fname) {
if (zend_hash_find(EG(function_table), func-fname,
strlen(func-fname) + 1, (void**) fptr) == FAILURE) {
}
when func-fname is not lowercase cause a PHP warning:
Warning: Internal error: Cannot find extension function
qrcode_encodeString in global function table in Unknown on line 0
Test script:
---
no
Expected result:
no
Actual result:
--
no
--
Edit this bug report at http://bugs.php.net/bug.php?id=54347edit=1
Bug #54924 [Com]: assert.active is not being reset upon request shutdown
Edit report at http://bugs.php.net/bug.php?id=54924edit=1 ID: 54924 Comment by: steemann at globalpark dot de Reported by:andreas dot streichardt at gmail dot com Summary:assert.active is not being reset upon request shutdown Status: Open Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Same issue for assert.warning (ASSERT_WARNING). The value is not reset to the ini setting value at the end of each request if PHP child processes are reused (e.g. in fastcgi mode). Probably the same for assert.bail and friends. Previous Comments: [2011-05-25 13:48:50] andreas dot streichardt at gmail dot com Description: The assert related functions are saving their state in a global structure. The problem is that the assert state is not being reset in the RSHUTDOWN function and thus the assert state of the last request will be used for the next request. Example: If assert is active by default (php.ini assert.active) and you set it to false via assert_options this works fine. However on the next request the default will be that assert is not active. The fix is to add ASSERTG(active)=INI_INT(assert.active); to asserts RSHUTDOWN function. I am using the FastCGI SAPI. Test script: --- var_dump(assert_options(ASSERT_ACTIVE)); assert(false); var_dump(assert_options(ASSERT_ACTIVE,1)); assert(false); var_dump(assert_options(ASSERT_ACTIVE,0)); assert(false); Expected result: int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 3 int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 5 int(1) Actual result: -- First request: int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 3 int(1) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 5 int(1) Second request (make sure you hit the same pid): int(0) int(0) Warning: assert() [function.assert]: Assertion failed in xxx.php on line 5 int(1) -- Edit this bug report at http://bugs.php.net/bug.php?id=54924edit=1
[PHP-BUG] Bug #54925 [NEW]: build php on solaris for 64 bits
From:
Operating system: solaris
PHP version: 5.2.17
Package: *General Issues
Bug Type: Bug
Bug description:build php on solaris for 64 bits
Description:
Build php on solaris with Sun compiler:
The default build for 64 bits, i.e. CFLAGS='-m64' produces strange
results.
Rebuilding all with CFLAGS='-m64 -O -xs -xstrconst -zlazyload' seems to
work.
To reproduce it:
$obj[0]['data'][0]['Usr'] = 0.009035;
echo json_encode($obj);
with just CFLAGS='-m64'
[{data:[{Usr:INF}]}]
with CFLAGS='-m64 -O -xs -xstrconst -zlazyload'
[{data:[{Usr:0.009035}]}]
which is correct.
may be a problem in main/snprintf.c and in main/spprintf.c
regards
Test script:
---
$obj[0]['data'][0]['Usr'] = 0.009035;
echo json_encode($obj);
Expected result:
[{data:[{Usr:0.009035}]}]
Actual result:
--
[{data:[{Usr:INF}]}]
--
Edit bug report at http://bugs.php.net/bug.php?id=54925edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54925r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54925r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54925r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54925r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54925r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54925r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54925r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54925r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54925r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54925r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54925r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54925r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54925r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54925r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54925r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54925r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54925r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54925r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54925r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54925r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54925r=mysqlcfg
[PHP-BUG] Bug #54926 [NEW]: preg_match causes segfault with specific subject
From:
Operating system: Solaris 10
PHP version: 5.3.6
Package: PCRE related
Bug Type: Bug
Bug description:preg_match causes segfault with specific subject
Description:
A customer page (system made in Drupal) was causing segfaults. After much
debugging, I found this line to cause it :
$contents = preg_replace('
\s*([@{}:;,]|\)\s|\s\()\s* | # Remove whitespace around
separators, but keep space around parentheses.
/\*([^*]|\*(?!/))+\*/ | # Remove comments that are not CSS
hacks.
[\n\r]# Remove line breaks.
x', '\1', $contents);
The $contents was a CSS file. After experimenting, it turns out that
opening a comment string (/*) followed by 1815 characters segfaults
Apache.
The same script runs perfectly fine when run from CLI, but segfaults on
Apache 2.2. It also runs well on several Linux environments tested.
Test script:
---
PHP-file :
?php
$contents = file_get_contents('temp.css');
$contents = preg_replace('
\s*([@{}:;,]|\)\s|\s\()\s* | # Remove whitespace around
separators, but keep space around parentheses.
/\*([^*]|\*(?!/))+\*/ | # Remove comments that are not CSS
hacks.
[\n\r]# Remove line breaks.
x', '\1', $contents);
echo $contents;
CSS-file :
/*
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
Expected result:
string(1797)
/*123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567
Bug #54926 [Opn]: preg_match causes segfault with specific subject
Edit report at http://bugs.php.net/bug.php?id=54926edit=1
ID: 54926
User updated by:wim at godden dot net
Reported by:wim at godden dot net
Summary:preg_match causes segfault with specific subject
Status: Open
Type: Bug
Package:PCRE related
Operating System: Solaris 10
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
We discovered the cause... not due to PHP, but purely due to the fact
that PCRE doesn't respect PHP memory limits. The Apache installation was
running in worker MPM model, not in prefork model and that apparently
caused the issue.
We switched to prefork and everything works fine now.
Previous Comments:
[2011-05-25 15:20:17] wim at godden dot net
Description:
A customer page (system made in Drupal) was causing segfaults. After
much debugging, I found this line to cause it :
$contents = preg_replace('
\s*([@{}:;,]|\)\s|\s\()\s* | # Remove whitespace around
separators, but keep space around parentheses.
/\*([^*]|\*(?!/))+\*/ | # Remove comments that are not CSS
hacks.
[\n\r]# Remove line breaks.
x', '\1', $contents);
The $contents was a CSS file. After experimenting, it turns out that
opening a comment string (/*) followed by 1815 characters segfaults
Apache.
The same script runs perfectly fine when run from CLI, but segfaults on
Apache 2.2. It also runs well on several Linux environments tested.
Test script:
---
PHP-file :
?php
$contents = file_get_contents('temp.css');
$contents = preg_replace('
\s*([@{}:;,]|\)\s|\s\()\s* | # Remove whitespace around
separators, but keep space around parentheses.
/\*([^*]|\*(?!/))+\*/ | # Remove comments that are not CSS
hacks.
[\n\r]# Remove line breaks.
x', '\1', $contents);
echo $contents;
CSS-file :
/*
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
Expected result:
string(1797)
/*123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567
Bug #54926 [Opn-Csd]: preg_match causes segfault with specific subject
Edit report at http://bugs.php.net/bug.php?id=54926edit=1
ID: 54926
User updated by:wim at godden dot net
Reported by:wim at godden dot net
Summary:preg_match causes segfault with specific subject
-Status: Open
+Status: Closed
Type: Bug
Package:PCRE related
Operating System: Solaris 10
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Closing... fixed - was an Apache issue
Previous Comments:
[2011-05-25 16:40:34] wim at godden dot net
We discovered the cause... not due to PHP, but purely due to the fact
that PCRE doesn't respect PHP memory limits. The Apache installation was
running in worker MPM model, not in prefork model and that apparently
caused the issue.
We switched to prefork and everything works fine now.
[2011-05-25 15:20:17] wim at godden dot net
Description:
A customer page (system made in Drupal) was causing segfaults. After
much debugging, I found this line to cause it :
$contents = preg_replace('
\s*([@{}:;,]|\)\s|\s\()\s* | # Remove whitespace around
separators, but keep space around parentheses.
/\*([^*]|\*(?!/))+\*/ | # Remove comments that are not CSS
hacks.
[\n\r]# Remove line breaks.
x', '\1', $contents);
The $contents was a CSS file. After experimenting, it turns out that
opening a comment string (/*) followed by 1815 characters segfaults
Apache.
The same script runs perfectly fine when run from CLI, but segfaults on
Apache 2.2. It also runs well on several Linux environments tested.
Test script:
---
PHP-file :
?php
$contents = file_get_contents('temp.css');
$contents = preg_replace('
\s*([@{}:;,]|\)\s|\s\()\s* | # Remove whitespace around
separators, but keep space around parentheses.
/\*([^*]|\*(?!/))+\*/ | # Remove comments that are not CSS
hacks.
[\n\r]# Remove line breaks.
x', '\1', $contents);
echo $contents;
CSS-file :
/*
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
Expected result:
string(1797)
Bug #44901 [Com]: open_basedir as prefix complains on attempts to access non-existant files
Edit report at http://bugs.php.net/bug.php?id=44901edit=1
ID: 44901
Comment by: softwareelves at gmail dot com
Reported by:jake at yahoo-inc dot com
Summary:open_basedir as prefix complains on attempts to
access non-existant files
Status: Verified
Type: Bug
Package:Safe Mode/open_basedir
Operating System: *
PHP Version:5.*, 6CVS (2009-03-16)
Block user comment: N
Private report: N
New Comment:
This bug doesn't seem to exist in 5.2.x.
I found it's not just a trailing slash but anything after an existing
file path.
I found an easy way to show this bug:
error_reporting( E_ALL | E_STRICT );
var_dump( file_exists( __FILE__ ) );
var_dump( file_exists( __FILE__./something_that_doesnt_exists ) );
ini_set( open_basedir, dirname( __FILE__ ) );
var_dump( file_exists( __FILE__ ) );
var_dump( file_exists( __FILE__./something_that_doesnt_exists ) );
Previous Comments:
[2008-05-03 00:41:11] jake at yahoo-inc dot com
Description:
When using open_basedir as a prefix, attempting to access files or
directories which match the prefix but are not present on the filesystem
raise open_basedir restriction warnings.
Reproduce code:
---
// create files or directories on the file system /foo1, /foo2
// add /foo (not /foo/) to the open basedir restriction, then:
var_dump(file_exists('/foo1'));
var_dump(file_exists('/foo2'));
var_dump(file_exists('/foo3'));
Expected result:
this is the output returned:
bool(true)
bool(true)
bool(false)
which is expected, however, the false returned by the third call is
disingenuous... it is false because the call is being blocked by
open_basedir, and the following warning is triggered:
[Fri May 2 17:33:05 2008] [error] PHP Warning: file_exists():
open_basedir restriction in effect. File(/foo3) is not within the
allowed path(s)
--
Edit this bug report at http://bugs.php.net/bug.php?id=44901edit=1
[PHP-BUG] Bug #54928 [NEW]: SoapServer handling SoapHeader and __call method
From: Operating system: Linux Ubuntu 11.04 PHP version: 5.3.6 Package: SOAP related Bug Type: Bug Bug description:SoapServer handling SoapHeader and __call method Description: In order to illustrate the problem, I use the test file http://svn.php.net/viewvc/php/php-src/trunk/ext/soap/tests/server021.phpt?revision=296679view=co Then I changed with the code at http://pastebin.com/SV82M47K and it raised 2 warning and SoapServer::handle() returned no xml output. The SoapServer::addSoapHeader must be called during the handle() execution. Then I had to inject the SoapServer instance inside the class used for SOAP servicing. Please note that with this code http://pastebin.com/jL6c1rsK (no more __call magic method use, a public fixed method called test) the result is as expected. So, the SoapServer can't handle a SoapServer::addSoapHeader() call inside a class that has the magic method __call(). Test script: --- Here is the code that doesn't work : http://pastebin.com/SV82M47K Here is a code example (send header on destruction) that works : http://pastebin.com/ZKnp4vPP Expected result: The result should be as following (see the header content) : ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns1=answers xmlns:ns2=http://testuri.org; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;SOAP-ENV:Headerns1:everything42/ns1:everything/SOAP-ENV:HeaderSOAP-ENV:Bodyns2:testResponsereturn xsi:type=xsd:stringHello World/return/ns2:testResponse/SOAP-ENV:Body/SOAP-ENV:Envelope ok Actual result: -- The result I obtained is : ok The SoapServer raises the 2 following warnings PHP Warning: Invalid callback , no array or string given in index.php on line 34 PHP Warning: SoapServer::handle(): Function '(null)' call failed in index.php on line 34 -- Edit bug report at http://bugs.php.net/bug.php?id=54928edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54928r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54928r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54928r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54928r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54928r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54928r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54928r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54928r=needscript Try newer version: http://bugs.php.net/fix.php?id=54928r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54928r=support Expected behavior: http://bugs.php.net/fix.php?id=54928r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54928r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54928r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54928r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54928r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54928r=dst IIS Stability: http://bugs.php.net/fix.php?id=54928r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54928r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54928r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54928r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54928r=mysqlcfg
Req #41856 [Com]: support for anonymous classes
Edit report at http://bugs.php.net/bug.php?id=41856edit=1
ID: 41856
Comment by: urkle at outoforder dot cc
Reported by:mbaynton at gmail dot com
Summary:support for anonymous classes
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
David, I do not believe you are understanding the request here.
I believe this is more what is being requested.
class Base {
private $name;
public function __construct($name) {
$this-name = $name;
}
public function test() {
return $this-name;
}
}
$obj = new class extends Base {
public function test() {
return ''.$this-name.'';
}
};
echo $obj-test();
Basically similar to that of anonymous functions introduced in PHP 5.3
Previous Comments:
[2010-09-26 19:41:30] david dot o dot greenberg at gmail dot com
The benefits of anonymous classes are twofold:
a) efficiency of code
b) efficiency of use of resources
consider:
$Div = new DivElement($InnerHTML = 'hello');
$Div-display();
versus:
(new DivElement( $InnerHTML = 'hello'))-display();
Lines of unnecessary code are saved, plus memory is allocated more
efficiently.
This is especially useful for objects that merely appear for a single
purpose and then vanish.
[2010-05-07 02:10:11] jevon at jevon dot org
Another request for anonymous classes. Without support for anonymous
classes, it can sometimes be necessary to create hundreds of named, and
rarely used, classes. Anonymous classes are often used for quick
instances that are created and destroyed quickly, so a performance hit
is reasonable.
[2008-11-11 06:24:37] igorsf at yahoo dot com
+1
[2007-06-29 19:12:50] mbaynton at gmail dot com
Description:
Just voicing my opinion that it would be nice to be able to create
anonymous inner classes as in Java.
Or put another way, I wish something like the reproduce code would work.
This looks much better than creating and naming a global class that has
some trivial purpose, like the one in the example.
Reproduce code:
---
if(! is_object($this-movie))
{
$this-movie = new __Object()
{
public function __call($name, $args)
{
return false;
}
};
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=41856edit=1
[PHP-BUG] Bug #54929 [NEW]: Parse error with single quote in sql comment (pdo-mysql)
From:
Operating system: linux (centos 5.5)
PHP version: 5.2.17
Package: PDO related
Bug Type: Bug
Bug description:Parse error with single quote in sql comment (pdo-mysql)
Description:
Using php 5.2.17
Tested PDO with mysql, haven't tried other drivers.
Configure Command = './configure' '--disable-cgi' '--with-mysql'
'--enable-pdo' '--with-pdo-mysql' '--with-libdir=lib64'
There is a PDO parsing error when a single quote is inside a block comment.
This seems to only occur when there is an input parameter between a
commented single quote and any other single quote, either as part of the
query or in another comment.
It looks like the single quotes aren't getting ignored in the comment, and
cause parameters to not be replaced with their values.
Example SQL that causes a parse error:
/* ' */ select ? as f1, 'foo' as f2
This also causes errors:
/* ' */ select ? as f1 /* ' */
Test script:
---
?
//This query breaks:
$query = /* ' */ select ? as f1, 'bar' as f2;
//This query also breaks:
//$query = /* ' */ select ? as f1 /* ' */;
$pdodb = new PDO(mysql:dbname=test;host=127.0.0.1, testuser,
testuser);
$stmt = $pdodb-prepare($query);
if (!$stmt-execute(array(foo))) {
$errInfo = $stmt-errorInfo();
print_r($errInfo);
}
?
Expected result:
The single quotes should be completely ignored when inside comments, and
the ? should be replaced with the input parameter value 'foo'.
Actual result:
--
The query doesn't execute successfully, with the following PDO error info:
[0] = 42000
[1] = 1064
[2] = You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near
'? as f1, 'bar' as f2' at line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=54929edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54929r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54929r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54929r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54929r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54929r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54929r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54929r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54929r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54929r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54929r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54929r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54929r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54929r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54929r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54929r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54929r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54929r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54929r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54929r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54929r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54929r=mysqlcfg
[PHP-BUG] Bug #54930 [NEW]: Assigning a value inside a foreach leads to change a variable out of scope
From:
Operating system: any
PHP version: Irrelevant
Package: Arrays related
Bug Type: Bug
Bug description:Assigning a value inside a foreach leads to change a variable
out of scope
Description:
I'm not sure if it's the right behavior, but seems that PHP doing it wrong,
see the test script.
Test script:
---
$v = array();
$data = array('v1' = '0');
foreach($data as $k = $v)
;
foreach(array('v2' = '1') as $k = $v)
;
var_dump($data);
Expected result:
array(1) {
[v1]=
string(1) 0
}
Actual result:
--
array(1) {
[v1]=
string(1) 1
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54930edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54930r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54930r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54930r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54930r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54930r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54930r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54930r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54930r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54930r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54930r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54930r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54930r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54930r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54930r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54930r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54930r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54930r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54930r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54930r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54930r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54930r=mysqlcfg
[PHP-BUG] Bug #54931 [NEW]: print_r does not reset() array pointer
From: Operating system: Any PHP version: 5.3.6 Package: Arrays related Bug Type: Bug Bug description:print_r does not reset() array pointer Description: The PHP documentation states: Remember that print_r() will move the array pointer to the end. Use reset() to bring it back to beginning. But after using print_r() on an array, the array pointer is not reset. This is the same as Bug #8289 from PHP 4 in the year 2000: http://bugs.php.net/bug.php?id=8289 Test script: --- $arr['a'] = 'Apple'; $arr['b'] = 'Banana'; $arr['c'] = 'Corn'; print_r($arr); //reset($arr); while(list($k,$v) = each($arr)) echo $k = $v\n; Expected result: Since print_r moves the array pointer to the end I would expect FALSE to be returned by each() and nothing to be printed. However, I also note that foreach() has some side effects so perhaps this is not necessarily a bug but a documentation issue? foreach() notes: http://www.php.net/manual/en/control-structures.foreach.php Note: Unless the array is referenced, foreach operates on a copy of the specified array and not the array itself. foreach has some side effects on the array pointer. Don't rely on the array pointer during or after the foreach without resetting it. Actual result: -- Array ( [a] = Apple [b] = Banana [c] = Corn ) a = Apple b = Banana c = Corn -- Edit bug report at http://bugs.php.net/bug.php?id=54931edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54931r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54931r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54931r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54931r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54931r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54931r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54931r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54931r=needscript Try newer version: http://bugs.php.net/fix.php?id=54931r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54931r=support Expected behavior: http://bugs.php.net/fix.php?id=54931r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54931r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54931r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54931r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54931r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54931r=dst IIS Stability: http://bugs.php.net/fix.php?id=54931r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54931r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54931r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54931r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54931r=mysqlcfg
Bug #54930 [Opn-Bgs]: Assigning a value inside a foreach leads to change a variable out of scope
Edit report at http://bugs.php.net/bug.php?id=54930edit=1
ID: 54930
Updated by: pierr...@php.net
Reported by:dobrolyubov at gmail dot com
Summary:Assigning a value inside a foreach leads to change a
variable out of scope
-Status: Open
+Status: Bogus
Type: Bug
Package:Arrays related
Operating System: any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
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
more explanation here:
http://schlueters.de/blog/archives/141-References-and-foreach.html
Previous Comments:
[2011-05-25 23:04:42] dobrolyubov at gmail dot com
Description:
I'm not sure if it's the right behavior, but seems that PHP doing it
wrong, see the test script.
Test script:
---
$v = array();
$data = array('v1' = '0');
foreach($data as $k = $v)
;
foreach(array('v2' = '1') as $k = $v)
;
var_dump($data);
Expected result:
array(1) {
[v1]=
string(1) 0
}
Actual result:
--
array(1) {
[v1]=
string(1) 1
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54930edit=1
Bug #54931 [Opn-Tbd]: print_r does not reset() array pointer
Edit report at http://bugs.php.net/bug.php?id=54931edit=1 ID: 54931 Updated by: johan...@php.net Reported by:todd at magnifisites dot com Summary:print_r does not reset() array pointer -Status: Open +Status: To be documented Type: Bug Package:Arrays related Operating System: Any PHP Version:5.3.6 Block user comment: N Private report: N New Comment: As print_r is aimed as a debugging help we should document this as undefined behavior so we can change it any time. Users should still be advised to use reset() if they want a defined state. Previous Comments: [2011-05-25 23:27:57] todd at magnifisites dot com Description: The PHP documentation states: Remember that print_r() will move the array pointer to the end. Use reset() to bring it back to beginning. But after using print_r() on an array, the array pointer is not reset. This is the same as Bug #8289 from PHP 4 in the year 2000: http://bugs.php.net/bug.php?id=8289 Test script: --- $arr['a'] = 'Apple'; $arr['b'] = 'Banana'; $arr['c'] = 'Corn'; print_r($arr); //reset($arr); while(list($k,$v) = each($arr)) echo $k = $v\n; Expected result: Since print_r moves the array pointer to the end I would expect FALSE to be returned by each() and nothing to be printed. However, I also note that foreach() has some side effects so perhaps this is not necessarily a bug but a documentation issue? foreach() notes: http://www.php.net/manual/en/control-structures.foreach.php Note: Unless the array is referenced, foreach operates on a copy of the specified array and not the array itself. foreach has some side effects on the array pointer. Don't rely on the array pointer during or after the foreach without resetting it. Actual result: -- Array ( [a] = Apple [b] = Banana [c] = Corn ) a = Apple b = Banana c = Corn -- Edit this bug report at http://bugs.php.net/bug.php?id=54931edit=1
Bug #34783 [Com]: Contradictory errors using ArrayAccess
Edit report at http://bugs.php.net/bug.php?id=34783edit=1 ID: 34783 Comment by: tohru at reedom dot com Reported by:oliver dot graetz at gmx dot de Summary:Contradictory errors using ArrayAccess Status: Bogus Type: Bug Package:SPL related Operating System: WinXP, Debian Linux PHP Version:5.1.0RC1 Block user comment: N Private report: N New Comment: It's a bug since the current behavior breaks the Liskov's Substitution Principle when a subclass just overrides offsetGet(). http://www.oodesign.com/liskov-s-substitution-principle.html Previous Comments: [2010-08-03 16:27:49] georgwaechter at googlemail dot com Hi Oliver, in my opinion you are absolutely right! I'm struggling with this bug for months now. The interface ArrayAccess is actually really useless until some serious php developers undestand that its essential that ArrayAccess objects behave like normal arrays. For modern object oriented programming this is simply a must. Enhanced this means that all array related functions work with those objects too. The current implementation is not complete. Greets Georg [2005-10-07 23:09:33] oliver dot graetz at gmx dot de Perhaps there shouldn't be afix for the reference issues since they are not meant to happen looking at the interface. But $data['element']['element2']=hi; should definitely work! Perhaps a fix to look if the first part of this code is accessing an object instead of a real array has to be applied. An ordinary user sees nothing of a reference. Either fix this with ArrayAccess or completely yank the interface! I see a future where more and more framework code is pretending to be an array. If then users get this error message they won't understand the world. It's an array!? Where's the reference? Why the *#?* isn't this working? I hate PHP5! If you implement code so something can look like an array than it MUST be able to truely behave like an array. [2005-10-07 22:40:50] oliver dot graetz at gmx dot de Why did this work in 5.0.3 by using offsetGet() and can't be made to work in 5.1? Why would changing the interface to read offsetGet break anything other than the (up to now) few apps DEFINING it without the ampersand? 5.0 didn't complain about this at all and it worked. The issues caused by a simple change of the interface a far inferior to those caused by the only variables can be passed by reference some weeks ago. And you're avoiding more serious trouble in later versions when more and more applications are relying on the false behaviour? [2005-10-07 21:41:03] oliver dot graetz at gmx dot de Won't happen. I'm just a user of PHP. As a result, this is one more case where using a new feature becomes impossible by breaking BC (between 5.0 and 5.1). A yound and promising feature has to be left behind, ArrayAccess won't be in use any more in future projects by certain people since the desired behaviour can easily be achieved by using ordinary methods. Syntactic sugar going to hell. [2005-10-07 20:20:40] he...@php.net 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 Just to state this again: IT IS IMPOSSIBLE TO HAVE ARRAYACCESS DEAL WITH REFERENCES. If you don\'t like that statement i suggest you prove it wrong by writing a patch that actually works in all cases. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=34783 -- Edit this bug report at http://bugs.php.net/bug.php?id=34783edit=1
Bug #45712 [Csd-ReO]: $something == NaN returns true with 5.3, false with 5.2.*
Edit report at http://bugs.php.net/bug.php?id=45712edit=1
ID: 45712
Updated by: phi...@php.net
Reported by:for-bugs at hnw dot jp
Summary:$something == NaN returns true with 5.3, false with
5.2.*
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:Variables related
Operating System: *
PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-05)
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
Reopening because the associated test tests INF as well. However, this
is about INF:
// 5.3.7-dev (and all past PHP versions, afaict)
$inf = pow(0,-2); var_dump($inf==$inf); var_dump($inf===$inf); // false
true
// 5.4.0-dev
$inf = pow(0,-2); var_dump($inf==$inf); var_dump($inf===$inf); // true
true
Please explain.
And @jwvdveer, it was indeed fixed (in 5.3) and made to return false.
Previous Comments:
[2010-07-28 01:28:53] jwvdveer at gmail dot com
Please, reopen this bug. It's not working in PHP 5.3.3 on Windows
platform (released at 2010-07-21).
The behaviour of a comparison to NAN is the same as noted here.
It's not just a `me too`, but this thread shouln't have been closed.
[2008-08-07 08:36:33] tony2...@php.net
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.
[2008-08-07 07:37:04] tony2...@php.net
I'm testing a patch for it.
[2008-08-05 12:52:06] for-bugs at hnw dot jp
NaN is not exact number. So, NaN should not equals itself. Additionaly,
NaN == NaN is false in C. You can see behavior of C as follows.
$ cat nan.c
int main() {double d;d=(-1e300*1e300)/(1e300*1e300);if (d==d) return 1;
else return 2;}
$ gcc nan.c; ./a.out; echo $?
2
$
[2008-08-05 12:33:17] j...@php.net
That $nan == $nan should be true. (like it is with 5.3)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=45712
--
Edit this bug report at http://bugs.php.net/bug.php?id=45712edit=1
