Bug #51546 [Opn->Bgs]: If shorthand statement
Edit report at http://bugs.php.net/bug.php?id=51546&edit=1 ID: 51546 Updated by: ahar...@php.net Reported by: michaelozeryansky at hotmail dot com Summary: If shorthand statement -Status: Open +Status: Bogus Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.2.13 New Comment: As the note at the end of the manual page at http://au2.php.net/ternary hints at, the associativity of the ternary operator is not particularly obvious. We can't change this now due to potential backward compatibility issues. Previous Comments: [2010-04-13 04:23:52] michaelozeryansky at hotmail dot com Description: When I use nested shorthand if statements the result doesn't seem to follow what I expected. I am not sure if this is a bug, but the results are different in other languages. Test script: --- I wrote a c++ script to see what the results should be in another language cout << ((true) ?"a":(true) ?"b":"c") << endl; // result = a cout << ((true) ?"a":(false)?"b":"c") << endl; // result = a cout << ((false)?"a":(true) ?"b":"c") << endl; // result = b cout << ((false)?"a":(false)?"b":"c") << endl; // result = c Expected result: The PHP script should print out: a a b c Actual result: -- In the comments behind each line -- Edit this bug report at http://bugs.php.net/bug.php?id=51546&edit=1
[PHP-BUG] Bug #51546 [NEW]: If shorthand statement
From: Operating system: Linux PHP version: 5.2.13 Package: *General Issues Bug Type: Bug Bug description:If shorthand statement Description: When I use nested shorthand if statements the result doesn't seem to follow what I expected. I am not sure if this is a bug, but the results are different in other languages. Test script: --- I wrote a c++ script to see what the results should be in another language cout << ((true) ?"a":(true) ?"b":"c") << endl; // result = a cout << ((true) ?"a":(false)?"b":"c") << endl; // result = a cout << ((false)?"a":(true) ?"b":"c") << endl; // result = b cout << ((false)?"a":(false)?"b":"c") << endl; // result = c Expected result: The PHP script should print out: a a b c Actual result: -- In the comments behind each line -- Edit bug report at http://bugs.php.net/bug.php?id=51546&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51546&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51546&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51546&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51546&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51546&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51546&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51546&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51546&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51546&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51546&r=support Expected behavior: http://bugs.php.net/fix.php?id=51546&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51546&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51546&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51546&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51546&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51546&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51546&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51546&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51546&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51546&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51546&r=mysqlcfg
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: john dot smith dot 1964 at gmail dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: I am seeing this bug consistently on standard Windows builds such as 5.2.4 and 5.2.13. Our Server is: Windows NT 5.2 build 3790 Sample code is simple: On 5.2.4 it will result in "1450.:0" every time. On 5.2.4, other such *funny* values are 1701,1821,1951,2091,2101,2111,2121,2341,2351... On 5.2.13,the numbers 1700 and 1900 consistently return "colon-ized" results. This is a especially problematic, because 1700 and 1900 occur more frequently in our eCommerce app! This issue is a real problem for us. It has been touched on (but not solved) in at least Bugs 46376, 47716, 47304 and 47418. Previous Comments: [2010-03-27 14:19:44] johan...@php.net You are mentioned this version information: php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies This version is very different from the versions we provide. a) Ubuntu adds some custom patches b) Suhosin does major changes to the engine c) Xdebug as well as Zend Debugger do changes to our executor unit. All these components aren't supported here. [2010-03-27 12:50:58] codeslinger at compsalot dot com One further note, in the repro above, it has to be exactly 16 nines. by adding or removing a 9, it does not fail. Also, as far as I know, all of the failures have been on 32bit Intel cpu's. This probably will not fail on a 64bit cpu. [2010-03-27 12:22:12] codeslinger at compsalot dot com well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Req #51536 [Asn]: Add sapi binary location to php ini search path
Edit report at http://bugs.php.net/bug.php?id=51536&edit=1 ID: 51536 Updated by: paj...@php.net Reported by: ksin...@php.net Summary: Add sapi binary location to php ini search path Status: Assigned Type: Feature/Change Request Package: *Configuration Issues Operating System: Windows PHP Version: 5.2.13 Assigned To: pajoye New Comment: As I said in my first comment I don't think we can make this change in 5.2 or 5.3. However we could have alternative solutions. I will take a 2nd look at this problem (there is another report about the ini path priorities). But again, what's the deal with SxS and 5.2/5.3? We can't do that either. Previous Comments: [2010-04-12 23:44:45] ksin...@php.net Yes, the fix is not needed for FastCGI but it is required for SAPIs which compile as dlls. Installer currently sets PHPRC environment variable at system level. To make different versions of PHP pick different php.ini in a SxS environment, it should stop creating PHPRC environment variable. Without PHPRC, SAPIs which are dlls won't be able to reach correct php.ini without this bug fix. This fix will be required in both PHP 5.2 and PHP 5.3 so that both versions don't have dependency on PHPRC. If one version requires PHPRC and installer sets it for that version, other version is going to pick php.ini from location specified by PHPRC unless we make PHP look for php.ini in SAPI binary location first. I understand that we want to keep locations specified by PHPRC and IniFilePath higher priority than SAPI binary folder. Given this, can this be fixed for both PHP 5.2 and PHP 5.3? [2010-04-12 10:54:53] paj...@php.net hi, Yes, ini location detection is not so good right now and needs to be improved. However it has nothing to do with SxS per se. It is not need for FastCGI as one can use php-cgi.exe -c c:\phpxxx\php.ini. The installer could do that automatically, to support multiple install of the same versions (per site configuaration) or multiple install of various versions. I don't think we will and can make change this behavior in 5.2. Please note that SxS support won't be done for 5.2, trunk will have it, whatever will be this version. [2010-04-12 00:06:17] ksin...@php.net Description: PHP searches php.ini in the binary location which is retrieved using GetModuleFileName (first parameter to GetModuleFileName is NULL). This will return path to current *executable* which won't be path to php sapi binary in case of dlls. For IIS, location of w3wp.exe which is %windir%\system32\inetsrv\ will be added to php ini search path. Is this intentional? Can we change this code to make it look for php.ini in the folder where php sapi binary is present? Without this fix, users running non-cgi SAPIs are required to set PHPRC environment variable or IniFilePath registry key to make PHP pick php.ini in the php install folder. If this bug is fixed, windows installer can stop setting PHPRC path to [installdir] and will be able to support side-by-side (SxS) install of PHP 5.2 and PHP 5.3. For installer to support SxS install, this change is required in PHP 5.2 and PHP 5.3. If we are worried about this being breaking change, we can just *add* php sapi binary location to php ini search path. -- Edit this bug report at http://bugs.php.net/bug.php?id=51536&edit=1
Req #51536 [Asn]: Add sapi binary location to php ini search path
Edit report at http://bugs.php.net/bug.php?id=51536&edit=1 ID: 51536 Updated by: ksin...@php.net Reported by: ksin...@php.net Summary: Add sapi binary location to php ini search path Status: Assigned Type: Feature/Change Request Package: *Configuration Issues Operating System: Windows PHP Version: 5.2.13 Assigned To: pajoye New Comment: Yes, the fix is not needed for FastCGI but it is required for SAPIs which compile as dlls. Installer currently sets PHPRC environment variable at system level. To make different versions of PHP pick different php.ini in a SxS environment, it should stop creating PHPRC environment variable. Without PHPRC, SAPIs which are dlls won't be able to reach correct php.ini without this bug fix. This fix will be required in both PHP 5.2 and PHP 5.3 so that both versions don't have dependency on PHPRC. If one version requires PHPRC and installer sets it for that version, other version is going to pick php.ini from location specified by PHPRC unless we make PHP look for php.ini in SAPI binary location first. I understand that we want to keep locations specified by PHPRC and IniFilePath higher priority than SAPI binary folder. Given this, can this be fixed for both PHP 5.2 and PHP 5.3? Previous Comments: [2010-04-12 10:54:53] paj...@php.net hi, Yes, ini location detection is not so good right now and needs to be improved. However it has nothing to do with SxS per se. It is not need for FastCGI as one can use php-cgi.exe -c c:\phpxxx\php.ini. The installer could do that automatically, to support multiple install of the same versions (per site configuaration) or multiple install of various versions. I don't think we will and can make change this behavior in 5.2. Please note that SxS support won't be done for 5.2, trunk will have it, whatever will be this version. [2010-04-12 00:06:17] ksin...@php.net Description: PHP searches php.ini in the binary location which is retrieved using GetModuleFileName (first parameter to GetModuleFileName is NULL). This will return path to current *executable* which won't be path to php sapi binary in case of dlls. For IIS, location of w3wp.exe which is %windir%\system32\inetsrv\ will be added to php ini search path. Is this intentional? Can we change this code to make it look for php.ini in the folder where php sapi binary is present? Without this fix, users running non-cgi SAPIs are required to set PHPRC environment variable or IniFilePath registry key to make PHP pick php.ini in the php install folder. If this bug is fixed, windows installer can stop setting PHPRC path to [installdir] and will be able to support side-by-side (SxS) install of PHP 5.2 and PHP 5.3. For installer to support SxS install, this change is required in PHP 5.2 and PHP 5.3. If we are worried about this being breaking change, we can just *add* php sapi binary location to php ini search path. -- Edit this bug report at http://bugs.php.net/bug.php?id=51536&edit=1
Bug #50394 [Com]: Reference argument converted to value in __call
Edit report at http://bugs.php.net/bug.php?id=50394&edit=1 ID: 50394 Comment by: tog7yt at yahoo dot com Reported by: tstarling at wikimedia dot org Summary: Reference argument converted to value in __call Status: Closed Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.1 New Comment: hljlkkga pbugs me Previous Comments: [2010-04-07 05:59:03] clark4220 at yahoo dot com PLEASE EXPLAIN THE TRUE NATURE OF THE DISAGREEMENT [2010-03-21 22:01:32] tstarling at wikimedia dot org This bug was fixed in 5.3.2. The problem you reported on mediawiki.org was not a PHP bug. [2010-03-21 21:57:04] spam dot here at verizon dot net Mediawiki still reports that the problem still exists. http://www.mediawiki.org/wiki/Project:Support_desk#PHP_5.3_Problem_Still_Exists And it is still in their install document. http://www.mediawiki.org/wiki/Installation "PHP version 5.1 or later (5.2.x recommended). PHP 5.3.1 is incompatible with MediaWiki due to a bug." [2009-12-18 19:20:33] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revision&revision=292296 Log: Fixed bug #50394 (Reference argument converted to value in __call) [2009-12-18 19:13:37] s...@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. fixed, thanks 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=50394 -- Edit this bug report at http://bugs.php.net/bug.php?id=50394&edit=1
[PHP-BUG] Req #51544 [NEW]: instanceof for static calls
From:
Operating system: Windows XP
PHP version: 5.3.2
Package: Reflection related
Bug Type: Feature/Change Request
Bug description:instanceof for static calls
Description:
Hy guys,
Here's a problem i faced today : i wanted to know if a base and derived
class having only static functions and using both late static binding were
an implementation of a specific interface.
The problem was that the class base needed to know if its child implemented
a specific interface.
Not easy to explain, the code is easier for a better comprehension :
Test script:
---
Expected result:
Normally the result should be 'iTest' because the class 'child' implements
iTest
Actual result:
--
Doesn't execute.
Here's the solution i found : i used the ReflectionCLass to emulate that
feature
getInterfaceNames())) echo 'iTest';
}
}
class child extends base implements iTest {
protected static $SELF = __CLASS__;
}
child::create();
?>
--
Edit bug report at http://bugs.php.net/bug.php?id=51544&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51544&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51544&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51544&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51544&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51544&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51544&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51544&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51544&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51544&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51544&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51544&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51544&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51544&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51544&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51544&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51544&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51544&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51544&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51544&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51544&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51544&r=mysqlcfg
Bug #51534 [Bgs]: DOMImplementation::createDocument() does not correctly append children
Edit report at http://bugs.php.net/bug.php?id=51534&edit=1
ID: 51534
User updated by: jameswithers89 at googlemail dot com
Reported by: jameswithers89 at googlemail dot com
Summary: DOMImplementation::createDocument() does not correctly
append children
Status: Bogus
Type: Bug
Package: DOM XML related
Operating System: Fedora 12 GNU/Linux
PHP Version: 5.3.2
New Comment:
At http://www.w3.org/TR/DOM-Level-3-Core/introduction.html it states
"Each
document contains zero or one doctype nodes, one document element node,
and zero
or more comments or processing instructions; the document element serves
as the
root of the element tree for the document". Correct me if I'm wrong but
if that
is the case then shouldn't the product of:
$document =
$implementation->createDocument('http://www.w3.org/1999/xhtml',
'html', $doctype);
use the method DOMNode::appendChild() 'correctly' and place the child
element
within its tags (as a child) rather than next to it (as a sibling)?
In the meantime, the following code gets the desired effect. It does
seem a
rather long way of locating the document/root element and appending a
child to
it:
createDocumentType('html');
$document =
$implementation->createDocument('http://www.w3.org/1999/xhtml',
'html', $doctype);
$head = $document->createElement('head');
$html = $document->getElementsByTagName('html');
$html = $html->item(0);
$html->appendChild($head);
echo $document->saveXML();
Previous Comments:
[2010-04-12 16:40:02] rricha...@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
It's appending exactly where you are telling it to
[2010-04-11 19:58:30] jameswithers89 at googlemail dot com
The following code also produces the same error:
createDocumentType('html');
// Don't create a root element...
$document = $implementation->createDocument(null, null, $doctype);
// ...instead create a element and set the xmlns attribute:
$html = $document->createElement('html');
$html->setAttribute('xmlns', 'http://www.w3.org/1999/xhtml');
$document->appendChild($html);
$head = $document->createElement('head');
$document->appendChild($head);
echo $document->saveHTML();
[2010-04-11 19:40:38] jameswithers89 at googlemail dot com
Description:
The product of DOMDocument::createDocument() appends children outside of
the qualified name of the document element (i.e. the root element).
I am using php-5.3.2-1.fc12.i686 and php-xml-5.3.2-1.fc12.i686 installed
using Yellowdog Updater, Modified Package Manager. All other DOM methods
tried so far work fine.
Test script:
---
createDocumentType('html');
$document =
$implementation->createDocument('http://www.w3.org/1999/xhtml', 'html',
$doctype);
$head = $document->createElement('head');
$document->appendChild($head);
echo $document->saveHTML();
Expected result:
http://www.w3.org/1999/xhtml";>
Actual result:
--
http://www.w3.org/1999/xhtml";>
--
Edit this bug report at http://bugs.php.net/bug.php?id=51534&edit=1
Bug #45786 [Csd]: FastCGI process exited unexpectedly
Edit report at http://bugs.php.net/bug.php?id=45786&edit=1 ID: 45786 Updated by: paj...@php.net Reported by: karelevzen at gmail dot com Summary: FastCGI process exited unexpectedly Status: Closed Type: Bug Package: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: dmitry New Comment: Did you enable mbstring as well? And put it before exif in the list? Exif requires mbstring. However that's unrelated to this bug, please ask for support on the PHP windows mailing list (or any other support channel). Previous Comments: [2010-04-12 19:11:02] differentpk at gmail dot com I had the same problem like error 500, I set all extentions off and the problem was gone. Then i uncommented extentions one by one and found that the problems occures at ;extension=php_exif.dll. Though i removed the error message but i am still unable to find the solution yet. [2008-08-26 09:59:12] dmi...@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-18 18:45:10] karelevzen at gmail dot com If this helps, I have created a dump 6 seconds after executing the page. Thread 0: ntdll!NtDelayExecution+15 kernel32!SleepEx+62 kernel32!Sleep+f php5ts!php_get_inf+1eaf php5ts!execute+cc5 php5ts!execute+6130 Thread 1: user32!NtUserGetMessage+15 user32!GetMessageA+a2 php5ts!zend_timeout+1a8 Another thing I found interesting is, that upon the request, a php-cgi.exe is created and does nothing. After the timeout, in the same exact moment, a new php-cgi.exe is created, the old php-cgi.exe is destroyed and the page is rendered. Is this behaviour normal or should I futher investigate this strange process? This second php-cgi.exe process is destroyed upon refresh and the display of the IIS error message. [2008-08-18 15:58:20] karelevzen at gmail dot com No succes, sorry. It behaves the same, eg. it loads the content, then keeps "loading" for some time (faulty php module). This time, the GUI error message DOES NOT APPER, but when I hit refresh, it displays a IIS error message stating: HTTP Error 500.0 - Internal Server Error Module FastCgiModule NotificationExecuteRequestHandler Handler PHP Error Code 0x8007000d After another refresh the page again loads, keeps on loading for a while, than, after another refresh the same error appears. IMHO it's the same problem, but this time IIS realizes that an error had occured when the second request is received. Due to the GUI error not showing, I cannot send you a crushdump. [2008-08-18 11:03:30] dmi...@php.net Could you please retest CVS. 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=45786 -- Edit this bug report at http://bugs.php.net/bug.php?id=45786&edit=1
Bug #45786 [Com]: FastCGI process exited unexpectedly
Edit report at http://bugs.php.net/bug.php?id=45786&edit=1 ID: 45786 Comment by: differentpk at gmail dot com Reported by: karelevzen at gmail dot com Summary: FastCGI process exited unexpectedly Status: Closed Type: Bug Package: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: dmitry New Comment: I had the same problem like error 500, I set all extentions off and the problem was gone. Then i uncommented extentions one by one and found that the problems occures at ;extension=php_exif.dll. Though i removed the error message but i am still unable to find the solution yet. Previous Comments: [2008-08-26 09:59:12] dmi...@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-18 18:45:10] karelevzen at gmail dot com If this helps, I have created a dump 6 seconds after executing the page. Thread 0: ntdll!NtDelayExecution+15 kernel32!SleepEx+62 kernel32!Sleep+f php5ts!php_get_inf+1eaf php5ts!execute+cc5 php5ts!execute+6130 Thread 1: user32!NtUserGetMessage+15 user32!GetMessageA+a2 php5ts!zend_timeout+1a8 Another thing I found interesting is, that upon the request, a php-cgi.exe is created and does nothing. After the timeout, in the same exact moment, a new php-cgi.exe is created, the old php-cgi.exe is destroyed and the page is rendered. Is this behaviour normal or should I futher investigate this strange process? This second php-cgi.exe process is destroyed upon refresh and the display of the IIS error message. [2008-08-18 15:58:20] karelevzen at gmail dot com No succes, sorry. It behaves the same, eg. it loads the content, then keeps "loading" for some time (faulty php module). This time, the GUI error message DOES NOT APPER, but when I hit refresh, it displays a IIS error message stating: HTTP Error 500.0 - Internal Server Error Module FastCgiModule NotificationExecuteRequestHandler Handler PHP Error Code 0x8007000d After another refresh the page again loads, keeps on loading for a while, than, after another refresh the same error appears. IMHO it's the same problem, but this time IIS realizes that an error had occured when the second request is received. Due to the GUI error not showing, I cannot send you a crushdump. [2008-08-18 11:03:30] dmi...@php.net Could you please retest CVS. [2008-08-13 14:22:26] j...@php.net Dmitry, something fishy with request shutdown in fastcgi? Note the ini options used by the user: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 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=45786 -- Edit this bug report at http://bugs.php.net/bug.php?id=45786&edit=1
Bug #51524 [Com]: Class static method confusion
Edit report at http://bugs.php.net/bug.php?id=51524&edit=1
ID: 51524
Comment by: david71rj at gmail dot com
Reported by: david71rj at gmail dot com
Summary: Class static method confusion
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Windows 7/64
PHP Version: 5.3.2
New Comment:
But how this not is a bug?
What I don't understand is: if I call a method as static, $this cannot
exists, one
time that $this, for me is 'object of same class' and not 'object of any
class'.
As example, how useful it (use $this as secondary object) can be?
Bye.
Previous Comments:
[2010-04-12 11:48:46] paj...@php.net
My comment was supposed to land in #51527, this one is obviously not a
bug (bogus).
[2010-04-10 19:27:14] david71rj at gmail dot com
Not make sense, a call static is call static, don't can exist $this. In
counterpart, if the user need pass a object reference, he must be to
specific
how a parameter.
public function x($object = null){
if($object
&& get_class($object) == 'B') {
// Now make sense, but not is $this
}
}
Bye.
[2010-04-10 18:06:02] paj...@php.net
Not sure you can simply bogus it "because that's the way php4 works" :)
Should we not fix it in trunk instead? Or at least leave that request
open until we have a decision.
[2010-04-10 17:49:31] johan...@php.net
If a static method is called from an object context the callers $this is
sent. This i due to compatibility with the way PHP 4 worked.
[2010-04-10 03:37:23] david71rj at gmail dot com
Description:
If I use public method as static in a method of a second function, this
send $this
from second class, don't of the first.
Test script:
---
http://codepad.org/8hW4Qtbo
Expected result:
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[2]
2 => int 1
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[3] <<< OKAY
2 => int 1
Actual result:
--
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[2]
2 => int 1
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test2)[3] < WHY "test2" IF DON'T?
2 => int 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51524&edit=1
Req #38162 [Opn->Csd]: Cannot specify different config files by PHP version
Edit report at http://bugs.php.net/bug.php?id=38162&edit=1
ID: 38162
Updated by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Cannot specify different config files by PHP version
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package: Feature/Change Request
+Package: *General Issues
Operating System: Windows XP SP2
PHP Version: 5CVS-2006-07-20 (snap)
-Assigned To:
+Assigned To: rquadling
New Comment:
PHP now supports full version and SAPI specific configuration files.
Previous Comments:
[2006-07-26 11:52:07] RQuadling at GMail dot com
Stupid bloody site! Lost the file.
http://rquadling.php1h.com/ini_patch.diff.txt
[2006-07-22 22:28:20] RQuadling at GMail dot com
http://rquadling.phpnet.us/enhance_ini_and_registry__diff.txt
[2006-07-20 14:55:20] tony2...@php.net
Please upload the patch somewhere and put the link here.
[2006-07-20 14:24:32] RQuadling at GMail dot com
Description:
PHP doesn't allow for version specific config files (or registry
settings).
The following patch will allow this.
Index: main/php_ini.c
===
RCS file: /repository/php-src/main/php_ini.c,v
retrieving revision 1.143
diff -u -r1.143 php_ini.c
--- main/php_ini.c 4 Jul 2006 06:38:32 - 1.143
+++ main/php_ini.c 18 Jul 2006 08:36:34 -
@@ -293,6 +293,7 @@
static const char paths_separator[] = { ZEND_PATHS_SEPARATOR, 0
};
#ifdef PHP_WIN32
char *reg_location;
+ int version_specific;
#endif
env_location = getenv("PHPRC");
@@ -318,14 +319,17 @@
#ifdef PHP_WIN32
/* Add registry location */
- reg_location = GetIniPathFromRegistry();
- if (reg_location != NULL) {
- if (*php_ini_search_path) {
- strcat(php_ini_search_path, paths_separator);
+ /* RAQ : Add version specific registry location */
+ for (version_specific = MAX_VERSION_SPECIFIC ; version_specific
>=
NOT_VERSION_SPECIFIC ; --version_specific)
+ {
+ reg_location = GetIniPathFromRegistry(version_specific);
+ if (reg_location != NULL) {
+ if (*php_ini_search_path) {
+ strcat(php_ini_search_path,
paths_separator);
+ }
+ strcat(php_ini_search_path, reg_location);
+ efree(reg_location);
}
- strcat(php_ini_search_path, reg_location);
- efree(reg_location);
- }
#endif
/* Add cwd (only with CLI) */
@@ -428,6 +432,50 @@
}
}
}
+ /* RAQ : Search php%php-version%-%sapi-module-name%.ini file in
search path */
+ if (!fh.handle.fp) {
+ const char *fmt = "php%s-%s.ini";
+ char *ini_fname = emalloc(strlen(fmt) +
strlen(sapi_module.name) +
strlen(PHP_VERSION));
+ sprintf(ini_fname, fmt, PHP_VERSION, sapi_module.name);
+ fh.handle.fp = php_fopen_with_path(ini_fname, "r",
php_ini_search_path, &php_ini_opened_path TSRMLS_CC);
+ efree(ini_fname);
+ if (fh.handle.fp) {
+ fh.filename = php_ini_opened_path;
+ }
+ }
+ /* RAQ : Search
php%php-major-version%.%php-minor-version%.%php-release-version%-%sapi-module-name%.ini
file in search path */
+ if (!fh.handle.fp) {
+ const char *fmt = "php%d.%d.%d-%s.ini";
+ char *ini_fname = emalloc(strlen(fmt) +
strlen(sapi_module.name) +
6);
+ sprintf(ini_fname, fmt, PHP_MAJOR_VERSION,
PHP_MINOR_VERSION,
PHP_RELEASE_VERSION, sapi_module.name);
+ fh.handle.fp = php_fopen_with_path(ini_fname, "r",
php_ini_search_path, &php_ini_opened_path TSRMLS_CC);
+ efree(ini_fname);
+ if (fh.handle.fp) {
+ fh.filename = php_ini_opened_path;
+ }
+ }
+ /* RAQ : Search
php%php-major-version%.%php-minor-version%-%sapi-module-name%.ini file
in searc
Req #40046 [Com]: OpenSSL CRL generation support
Edit report at http://bugs.php.net/bug.php?id=40046&edit=1
ID: 40046
Comment by: pm at datasphere dot ch
Reported by: mbechler at eenterphace dot org
Summary: OpenSSL CRL generation support
Status: Assigned
Type:Feature/Change Request
Package: Feature/Change Request
PHP Version: 5.2.1RC2
Assigned To: pajoye
New Comment:
I'm also very interested in having this feature supported in the PHP
standards. Can I expect to see it soon available ?
Previous Comments:
[2010-02-15 09:07:32] cnyegle at gmail dot com
Will the patch be merged into PHP?It's two years after the last
modification of this issue.
[2007-09-23 19:51:19] paj...@php.net
>From Moritz Bechler:
It took some time - but I now managed to put together some test cases
(which hopefully can also serve as examples). I noticed that the
current
"openssl_x509_checkpurpose" function does not allow for passing
verification flags so I introduced a new function "openssl_x509_check"
(verify might be better but might cause confusion with openssl_verify)
which does pretty much the same thing but takes a flags parameter which
can be used to enable CRL checking and some other checking features
which I did not test yet. I chose to add a new function because a)
adding the argument to the end forces passing two (one unused in most
cases) optional arguments b) _checkpurpose is a bit too specific. I
hope
that approach is okay.
The updated patch is at
http://mbechler.eenterphace.org/php6-openssl-crl.patch
and the phpt and required data (needs a small CA, included files are
valid for 5 years) at
http://mbechler.eenterphace.org/php6-openssl-crl-tests.tar.bz2
I noted my test fails (even for ascii filenames) when run in unicode
mode which is a result of
this check in php_openssl_x509_from_zval:
if (!(Z_TYPE_PP(val) == IS_STRING || Z_TYPE_PP(val) == IS_OBJECT)) {
return NULL;
}
maybe I'll find some time to have a look at proper filesystem encoding
conversions for ext/openssl.
[2007-08-03 11:37:24] paj...@php.net
Add the note here too :)
Please provide some test cases as well, including the required data (if
any).
[2007-01-07 02:47:19] mbechler at eenterphace dot org
Ok, finally found the bug - new patch is here:
http://mbechler.eenterphace.org/ext-openssl-crl.patch
[2007-01-07 02:26:36] mbechler at eenterhace dot org
When trying to use the functionality in a real world scenario I noticed
problems with this patch. My FastCGI processes are throwing errors like
this *** corrupted double-linked list: 0x08a135f0 *** while it is
working nice when run from the command line. I could not get any helpful
information yet by debugging, but this one is definitly not ready for
inclusion. I'm trying to figure out what's wrong, but I am thankful for
any help provided.
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=40046
--
Edit this bug report at http://bugs.php.net/bug.php?id=40046&edit=1
Bug #46050 [Opn]: odbc_next_result corrupts prepared resource
Edit report at http://bugs.php.net/bug.php?id=46050&edit=1
ID: 46050
User updated by: RQuadling at GMail dot com
Reported by: RQuadling at GMail dot com
Summary: odbc_next_result corrupts prepared resource
Status: Open
Type: Bug
Package: ODBC related
Operating System: Windows XP SP3
PHP Version: 5.3.0alpha2
New Comment:
Using PDO-ODBC is fine.
// Connect to the SQL Server using a DNS-less connection.
// $r_Connection = odbc_pconnect("Driver={SQL
Server};Server={$s_Server};Database={$s_Database}", $s_Username,
$s_Password);
$r_Connection = new PDO("odbc:Driver={SQL Server Native Client
10.0};Server={$s_Server};Database={$s_Database}", $s_Username,
$s_Password);
// Prepare the statement.
// $r_Statement = odbc_prepare($r_Connection, "EXEC
{$s_Database}.dbo.{$s_StoredProc} ?");
$r_Statement = $r_Connection->prepare("EXEC
{$s_Database}.dbo.{$s_StoredProc}
?");
// Execute the statement for each parameter.
foreach($a_Params as $s_Param)
{
echo 'About to process : ', $s_Param, PHP_EOL;
// $b_Executed = odbc_execute($r_Statement, array($s_Param));
$b_Executed = $r_Statement->execute(array($s_Param));
do
{
// while(False !== ($a_Row = odbc_fetch_array($r_Statement)))
while(False !== ($a_Row = $r_Statement-
>fetch(PDO::FETCH_ASSOC)))
{
print_r($a_Row);
}
}
// while(True === ($b_MoreResults = odbc_next_result($r_Statement)));
while(True === ($b_MoreResults = $r_Statement->nextRowset()));
$r_Statement->closeCursor();
}
Previous Comments:
[2008-10-24 08:58:35] j...@php.net
Reclassified in correct category. And you should use PDO ODBC instead
anyway.
[2008-09-11 13:33:33] RQuadling at GMail dot com
Description:
Using PHP 5.3.0alpha3-dev (cli) (built: Sep 11 2008 09:01:08)
Using ODBC to talk to Microsoft SQL Server 7.
Using a prepared statement to run a Stored Procedure on the SQL
server.
Using the function odbc_next_result() to determine if there are more
result sets after having retrieved the first result sets kills the
prepared statement from re-use and results in an unhandled win32
exception.
The SP is not the issue and as a test is the following code:
CREATE PROCEDURE dbo.SimpleIdentity
@s_Identity AS VARCHAR(500)
AS
SELECT
@s_Identity AS [Simple Identity]
GO
Removing the odbc_next_result() loop makes everything work.
The example code below is from a larger code which deals with getting
data from an SP and caching the result(s). Currently I am unable to
retrieve multiple result sets AND use stored procedures together.
Reproduce code:
---
Richard
)
About to process : Simon
Array
(
[Simple Identity] => Simon
)
About to process : John
Array
(
[Simple Identity] => John
)
Actual result:
--
About to process : Richard
Array
(
[Simple Identity] => Richard
)
About to process : Simon
and then an unhandled win32 exception in php.cli
--
Edit this bug report at http://bugs.php.net/bug.php?id=46050&edit=1
Bug #48831 [PATCH]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1
ID: 48831
Patch added by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: php -i has different output to php --ini
Status: Assigned
Type: Bug
Package: CGI related
Operating System: *
PHP Version: 5.*, 6CVS (2009-07-07)
Assigned To: pajoye
New Comment:
The following patch has been added/updated:
Patch Name: ScanIniDir
Revision: 1271085810
URL:
http://bugs.php.net/patch-display.php?bug=48831&patch=ScanIniDir&revision=1271085810
Previous Comments:
[2009-08-24 12:48:57] RQuadling at GMail dot com
Missed an PHPAPI extern char *php_ini_scanned_path;
[2009-07-07 11:28:46] rquadl...@php.net
Typo: had => has
[2009-07-07 11:24:31] RQuadling at GMail dot com
Description:
If the environment variable PHP_INI_SCAN_DIR is set, then
php -i
outputs the path and any ini files.
If you enter
php --ini
the ini files are correct, but the scan directory is not.
php --ini is only showing the PHP_CONFIG_FILE_SCAN_DIR value rather
than the php_ini_scanned_path (which may be PHP_CONFIG_FILE_SCAN_DIR
if there is no PHP_INI_SCAN_DIR envvar).
Patch below
Index: php_cli.c
===
RCS file: /repository/php-src/sapi/cli/php_cli.c,v
retrieving revision 1.211
diff -u -r1.211 php_cli.c
--- php_cli.c 5 Jun 2009 18:50:10 - 1.211
+++ php_cli.c 7 Jul 2009 11:16:14 -
@@ -1360,7 +1360,7 @@
{
zend_printf("Configuration
File (php.ini) Path: %s\n", PHP_CONFIG_FILE_PATH);
zend_printf("Loaded
Configuration File: %s\n", php_ini_opened_path ?
php_ini_opened_path : "(none)");
- zend_printf("Scan for
additional .ini files in: %s\n", *PHP_CONFIG_FILE_SCAN_DIR ?
PHP_CONFIG_FILE_SCAN_DIR : "(none)");
+ zend_printf("Scan for
additional .ini files in: %s\n", php_ini_scanned_path ?
php_ini_scanned_path : "(none)");
zend_printf("Additional .ini
files parsed: %s\n", php_ini_scanned_files ?
php_ini_scanned_files : "(none)");
break;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #51530 [Opn->Bgs]: DOMDocument::createElement() does not handle correctly
Edit report at http://bugs.php.net/bug.php?id=51530&edit=1
ID: 51530
Updated by: rricha...@php.net
Reported by: jameswithers89 at googlemail dot com
Summary: DOMDocument::createElement() does not handle
correctly
-Status: Open
+Status: Bogus
Type: Bug
Package: DOM XML related
Operating System: Fedora 12 GNU/Linux
PHP Version: 5.3.2
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
use saveXML to produce XHTML. In regular HTML link tag has no closing
tag
Previous Comments:
[2010-04-11 02:16:01] jameswithers89 at googlemail dot com
Description:
DOMDocument::createElement() does not add a closing tag with
DOMDocument::createElement('link'). It outputs rather than
.
I am using php-5.3.2-1.fc12.i686 and php-xml-5.3.2-1.fc12.i686 installed
using Yellowdog Updater, Modified Package Manager. All other DOM methods
tried so far work fine.
Test script:
---
createDocument(null, null,
$implementation->createDocumentType('html'));
$html = $document->createElement('html');
$head = $document->createElement('head');
$stylesheet = $document->createElement('link');
$title = $document->createElement('title', 'Possible link error');
$body = $document->createElement('body');
$html->setAttribute('xmlns', 'http://www.w3.org/1999/xhtml');
$stylesheet->setAttribute('href','style.css');
$stylesheet->setAttribute('rel','stylesheet');
$stylesheet->setAttribute('type','text/css');
$document->appendChild($html);
$html->appendChild($head);
$html->appendChild($body);
$head->appendChild($stylesheet);
$head->appendChild($title);
echo $document->saveHTML();
Expected result:
http://www.w3.org/1999/xhtml";>
Possible link error
Actual result:
--
http://www.w3.org/1999/xhtml";>
Possible link error
--
Edit this bug report at http://bugs.php.net/bug.php?id=51530&edit=1
Bug #51534 [Opn->Bgs]: DOMImplementation::createDocument() does not correctly append children
Edit report at http://bugs.php.net/bug.php?id=51534&edit=1
ID: 51534
Updated by: rricha...@php.net
Reported by: jameswithers89 at googlemail dot com
Summary: DOMImplementation::createDocument() does not correctly
append children
-Status: Open
+Status: Bogus
Type: Bug
Package: DOM XML related
Operating System: Fedora 12 GNU/Linux
PHP Version: 5.3.2
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
It's appending exactly where you are telling it to
Previous Comments:
[2010-04-11 19:58:30] jameswithers89 at googlemail dot com
The following code also produces the same error:
createDocumentType('html');
// Don't create a root element...
$document = $implementation->createDocument(null, null, $doctype);
// ...instead create a element and set the xmlns attribute:
$html = $document->createElement('html');
$html->setAttribute('xmlns', 'http://www.w3.org/1999/xhtml');
$document->appendChild($html);
$head = $document->createElement('head');
$document->appendChild($head);
echo $document->saveHTML();
[2010-04-11 19:40:38] jameswithers89 at googlemail dot com
Description:
The product of DOMDocument::createDocument() appends children outside of
the qualified name of the document element (i.e. the root element).
I am using php-5.3.2-1.fc12.i686 and php-xml-5.3.2-1.fc12.i686 installed
using Yellowdog Updater, Modified Package Manager. All other DOM methods
tried so far work fine.
Test script:
---
createDocumentType('html');
$document =
$implementation->createDocument('http://www.w3.org/1999/xhtml', 'html',
$doctype);
$head = $document->createElement('head');
$document->appendChild($head);
echo $document->saveHTML();
Expected result:
http://www.w3.org/1999/xhtml";>
Actual result:
--
http://www.w3.org/1999/xhtml";>
--
Edit this bug report at http://bugs.php.net/bug.php?id=51534&edit=1
Bug #51512 [Opn->Csd]: Fails mb_send_mail* tests
Edit report at http://bugs.php.net/bug.php?id=51512&edit=1 ID: 51512 Updated by: il...@php.net Reported by: tsisaruk dot v at gmail dot com Summary: Fails mb_send_mail* tests -Status: Open +Status: Closed Type: Bug Package: mbstring related Operating System: Linux (gentoo) PHP Version: 5.3SVN-2010-04-08 (snap) -Assigned To: +Assigned To: iliaa New Comment: 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. Previous Comments: [2010-04-12 16:05:02] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=297898 Log: MFB: Fixed bug #51512 (mb_send_mail* fail when mail.add_x_header is on by default) [2010-04-12 16:04:47] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=297897 Log: Fixed bug #51512 (mb_send_mail* fail when mail.add_x_header is on by default) [2010-04-08 16:48:18] tsisaruk dot v at gmail dot com Description: Fails tests, because mail.add_x_header=on by default, and php add unexpected header. Patch fixes tests by turning off mail.add_x_header -- Edit this bug report at http://bugs.php.net/bug.php?id=51512&edit=1
Bug #51513 [Opn->Bgs]: Patch for test ext/gd/tests/bug48555.phpt
Edit report at http://bugs.php.net/bug.php?id=51513&edit=1 ID: 51513 Updated by: il...@php.net Reported by: tsisaruk dot v at gmail dot com Summary: Patch for test ext/gd/tests/bug48555.phpt -Status: Open +Status: Bogus Type: Bug Package: GD related Operating System: Linux (gentoo) PHP Version: 5.3SVN-2010-04-08 (snap) New Comment: It works fine without a patch, the patch would actually introduce "support" for non-working behavior. Previous Comments: [2010-04-08 17:17:15] tsisaruk dot v at gmail dot com Description: Patch for test ext/gd/tests/bug48555.phpt -- Edit this bug report at http://bugs.php.net/bug.php?id=51513&edit=1
[PHP-BUG] Bug #51542 [NEW]: Overriding method type hint with child interface raises strict standards
From:
Operating system: GNU/Linux
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Overriding method type hint with child interface raises strict
standards
Description:
When using an interface for type hinting, PHP raises a strict standards
warning
if an overriding method uses an interface that implements the type hint. In
the
example below, ITwo implements IOne and method One::foo expects the first
argument to implement IOne. Two extends One and expects the first argument
to
implement ITwo, which implements IOne. This should be allowed, much like it
is
allowed if the interfaces were simply classes.
Test script:
---
interface IOne {}
interface ITwo extends IOne {}
class One
{
public function foo( IOne $bla ) {}
}
class Two extends One
{
public function foo( ITwo $bla ) {}
}
class Test implements ITwo {}
// yet, this does work
var_dump( new Test instanceof IOne );
Expected result:
bool(true)
Actual result:
--
PHP Strict Standards: Declaration of Two::foo() should be compatible with
that
of One::foo() in test.php on line 25
Strict Standards: Declaration of Two::foo() should be compatible with that
of
One::foo() in test.php on line 25
bool(true)
--
Edit bug report at http://bugs.php.net/bug.php?id=51542&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51542&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51542&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51542&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51542&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51542&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51542&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51542&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51542&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51542&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51542&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51542&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51542&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51542&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51542&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51542&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51542&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51542&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51542&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51542&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51542&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51542&r=mysqlcfg
Bug #47279 [Com]: Symbol xmlTextReaderSetup definition was not found
Edit report at http://bugs.php.net/bug.php?id=47279&edit=1 ID: 47279 Comment by: praveen_parim at yahoo dot co dot in Reported by: johntmills at yahoo dot com Summary: Symbol xmlTextReaderSetup definition was not found Status: Bogus Type: Bug Package: Apache2 related Operating System: AIX537 PHP Version: 5.2.8 New Comment: #export LD_LIBRARY_PATH=/usr/local/lib That's all Previous Comments: [2009-02-09 13:43:15] johntmills at yahoo dot com I have confirmed this is a IBMIHS (apache2) issue. I was able to build the PHP tree versus a vanilla apache binary with no errors and full functionality. The LD_LIBRARY_PATH that is not being set is the one for the 'apachectl start' routine, not for the compilation of PHP. [2009-02-02 21:24:12] j...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Set your LD_LIBRARY_PATH properly. [2009-02-02 14:08:04] johntmills at yahoo dot com Description: Compilation yields no errors but upon start I get an undefined symbol error. Reproduce code: --- export LIBPATH=$LIBPATH:/apps/IBMIHS/lib/ export ORACLE_HOME=/apps/oracle/product/10.2/client export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib:$LD_LIBRARY_PATH export PATH=/usr/vac/bin:/usr/vacpp/bin:$PATH export CFLAGS="-I /usr/vac/include -I /usr/vacpp/include -I /usr/include -ma" export CXXFLAGS="-I /usr/vac/include -I /usr/vacpp/include -I /usr/include -ma" ./configure --with-apxs2=/apps/IBMIHS/bin/apxs --with-libxml-dir=/opt/libxml2/2.6.30 --with-mysql=/opt/mysql/5.0.67 --with-config-file-path=/apps/IBMIHS/conf --enable-maintainer-zts --prefix=/opt/php/5.2.8 --enable-sigchild --with-oci8=/apps/oracle/product/10.2/client make make -i install cp .libs/libphp5.a /apps/IBMIHS/modules/libphp5.a cp .libs/libphp5.lai /apps/IBMIHS/modules/libphp5.la cp -p .libs/libphp5.so /apps/IBMIHS/modules/libphp5.so chmod 755 /apps/IBMIHS/modules/libphp5.so Expected result: Apache restart without errors. Actual result: -- Syntax error on line 858 of /apps/IBM/WebSphere/CommerceServer60/instances/devcommerce1/httpconf/httpd.conf: Cannot load /apps/IBMIHS/modules/libphp5.so into server: rtld: 0712-001 Symbol xmlTextReaderSetup was referenced from module /apps/IBMIHS/modules/libphp5.so(), but a runtime definition of the symbol was not found. httpd.conf:858: ... # start PHP config LoadModule php5_module modules/libphp5.so AddType application/x-httpd-php .php .phtml AddType application/x-httpd-php-source .phps # ldd /apps/IBMIHS/modules/libphp5.so /apps/IBMIHS/modules/libphp5.so needs: /opt/mysql/5.0.67/lib/mysql/libmysqlclient_r.a(libmysqlclient_r.so.15) /usr/lib/libpthread.a(shr_xpg5.o) /usr/lib/libiconv.a(shr4.o) /usr/lib/libdl.a(shr.o) /usr/lib/libbsd_r.a(shr.o) /oracle/app/oracle/product/10.2.0/lib32/libclntsh.so /opt/libxml2/2.6.30/lib/libxml2.a(libxml2.so.2) /usr/lib/libc.a(shr.o) /usr/lib/librtl.a(shr.o) /usr/lib/libpthreads.a(shr_comm.o) /unix /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libodm.a(shr.o) /usr/lib/libperfstat.a(shr.o) /usr/lib/libcrypt.a(shr.o) /usr/lib/libcfg.a(shr.o) /usr/lib/liblvm.a(shr.o) -- Edit this bug report at http://bugs.php.net/bug.php?id=47279&edit=1
Bug #51527 [Bgs->Opn]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=1
ID: 51527
Updated by: paj...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
-Status: Bogus
+Status: Open
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
I don't like the optional flag idea. You can disable strictness using
error_reporting already.
However I would like to see this change in trunk, can you come up with a
RFC pls?
Previous Comments:
[2010-04-10 20:19:45] weierophin...@php.net
@johannes Perhaps an optional "strict" flag to is_callable() would
address this?
That would keep BC, while allowing for better checking for >= PHP-5
apps. Usage
would be:
$callback = array('Foo', 'bar');
if (is_callable($callback, true)) {
// Passed strict check
} else {
// failed strict check
}
Thoughts?
[2010-04-10 17:55:25] johan...@php.net
The method can always be called statically. The access to $this might be
forbidden but the method itself can be called. is_callable() doesn't
mean it will execute properly. (the $this error is basically the same as
a call to an undefined funciton in there or such)
To change this the only way would be to forbid calling non-static
methods statically. Maybe this can be done nowadays (we needed the
behavior for PHP 4 compatibility) but that's no bug but requires a RFC
and discussion on internals as this might break quite a few applications
(many PEAR-based things, many legacy applications not fully "converted"
to PHP 5 )
[2010-04-10 16:43:31] weierophin...@php.net
@pajoye: Yes, this particular example was callable. However, if the
method is
actually an instance method, and has references to $this, is_callable()
still
returns true -- making it an invalid test to use to determine whether or
not it's
safe to then call call_user_func(). Instead, to really determine if the
callback
is valid, you have to start doing a bunch of reflection -- checking to
see if the
method is defined and static, or if there is a __callStatic defined that
would
intercept the call.
That's the more serious implication of the behavior, and why it needs to
be
fixed.
[2010-04-10 16:29:12] paj...@php.net
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback "array('Foo',
'bar')",
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527&edit=1
Bug #51524 [Opn->Bgs]: Class static method confusion
Edit report at http://bugs.php.net/bug.php?id=51524&edit=1
ID: 51524
Updated by: paj...@php.net
Reported by: david71rj at gmail dot com
Summary: Class static method confusion
-Status: Open
+Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Windows 7/64
PHP Version: 5.3.2
New Comment:
My comment was supposed to land in #51527, this one is obviously not a
bug (bogus).
Previous Comments:
[2010-04-10 19:27:14] david71rj at gmail dot com
Not make sense, a call static is call static, don't can exist $this. In
counterpart, if the user need pass a object reference, he must be to
specific
how a parameter.
public function x($object = null){
if($object
&& get_class($object) == 'B') {
// Now make sense, but not is $this
}
}
Bye.
[2010-04-10 18:06:02] paj...@php.net
Not sure you can simply bogus it "because that's the way php4 works" :)
Should we not fix it in trunk instead? Or at least leave that request
open until we have a decision.
[2010-04-10 17:49:31] johan...@php.net
If a static method is called from an object context the callers $this is
sent. This i due to compatibility with the way PHP 4 worked.
[2010-04-10 03:37:23] david71rj at gmail dot com
Description:
If I use public method as static in a method of a second function, this
send $this
from second class, don't of the first.
Test script:
---
http://codepad.org/8hW4Qtbo
Expected result:
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[2]
2 => int 1
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[3] <<< OKAY
2 => int 1
Actual result:
--
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test)[2]
2 => int 1
array
0 => string 'static' (length=6)
1 => int 1
array
0 => string 'object' (length=6)
1 =>
object(test2)[3] < WHY "test2" IF DON'T?
2 => int 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51524&edit=1
Doc #51541 [Opn]: ZipArchive::addFile does not really add files
Edit report at http://bugs.php.net/bug.php?id=51541&edit=1 ID: 51541 Updated by: paj...@php.net Reported by: juwe at clasennet dot de Summary: ZipArchive::addFile does not really add files Status: Open Type: Documentation Problem Package: Zip Related Operating System: Linux PHP Version: 5.3SVN-2010-04-12 (SVN) New Comment: This behavior was the same in previous before but you would not be able to actually delete the file (file lock). It should definitively be part of the documentation. Previous Comments: [2010-04-12 11:37:24] juwe at clasennet dot de Description: Could you please let the documentation for ZipArchive::addFile() reflect, that the function doesn't really add the added files content to the zip archive any longer? As it seems, the files content is only read when storing the files now, as opposed to 5.2.8. So, if you delete a file directly after adding it to a zip archive, the archive won't be created any longer. I'm not really sure, if this is a bug, since the return value of addFile() isn't true any longer, or if this is just a documentation problem. Personaly, I don't care either way. I just spend about two hours, until I realized where the problem was. Having a reminder in the docs would have reduced this time down to about five minutes... There is a bug report (#40494) talking about such information in the manual, but the bug was marked bogus, and the manual was never updated. Essentially, that's why I opened this one as a documentation problem. Test script: --- open($zipArchive,ZIPARCHIVE::CREATE)) foreach($filesToAdd as $file) if($zip->addFile($file,basename($file))) unlink($file); $zip->close(); /* Expected result: * Zip archive exists and contains the right data * * Actual result: * Version 5.2.8: * - Works flawlessly & as expected * Version 5.3.99-dev * - No zip archive created * - ZipArchive::GetStatusString reports a read error, * but only after closing the file */ ?> Expected result: Zip archive exists and contains the right data. Actual result: -- Version 5.2.8: - Works flawlessly & as expected Version 5.3.99-dev - No zip archive created - ZipArchive::GetStatusString reports a read error, but only after closing the file -- Edit this bug report at http://bugs.php.net/bug.php?id=51541&edit=1
[PHP-BUG] Doc #51541 [NEW]: ZipArchive::addFile does not really add files
From: Operating system: Linux PHP version: 5.3SVN-2010-04-12 (SVN) Package: Zip Related Bug Type: Documentation Problem Bug description:ZipArchive::addFile does not really add files Description: Could you please let the documentation for ZipArchive::addFile() reflect, that the function doesn't really add the added files content to the zip archive any longer? As it seems, the files content is only read when storing the files now, as opposed to 5.2.8. So, if you delete a file directly after adding it to a zip archive, the archive won't be created any longer. I'm not really sure, if this is a bug, since the return value of addFile() isn't true any longer, or if this is just a documentation problem. Personaly, I don't care either way. I just spend about two hours, until I realized where the problem was. Having a reminder in the docs would have reduced this time down to about five minutes... There is a bug report (#40494) talking about such information in the manual, but the bug was marked bogus, and the manual was never updated. Essentially, that's why I opened this one as a documentation problem. Test script: --- open($zipArchive,ZIPARCHIVE::CREATE)) foreach($filesToAdd as $file) if($zip->addFile($file,basename($file))) unlink($file); $zip->close(); /* Expected result: * Zip archive exists and contains the right data * * Actual result: * Version 5.2.8: * - Works flawlessly & as expected * Version 5.3.99-dev * - No zip archive created * - ZipArchive::GetStatusString reports a read error, * but only after closing the file */ ?> Expected result: Zip archive exists and contains the right data. Actual result: -- Version 5.2.8: - Works flawlessly & as expected Version 5.3.99-dev - No zip archive created - ZipArchive::GetStatusString reports a read error, but only after closing the file -- Edit bug report at http://bugs.php.net/bug.php?id=51541&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51541&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51541&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51541&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51541&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51541&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51541&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51541&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51541&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51541&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51541&r=support Expected behavior: http://bugs.php.net/fix.php?id=51541&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51541&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51541&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51541&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51541&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51541&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51541&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51541&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51541&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51541&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51541&r=mysqlcfg
[PHP-BUG] Bug #51540 [NEW]: insert data
From:
Operating system: win2003 server
PHP version: 5.2.13
Package: OCI8 related
Bug Type: Bug
Bug description:insert data
Description:
i use oci to insert data, but result is nothing
Test script:
---
$conn = oci_connect('username', 'password', 'HOST_IP/orcl',
'AR8MSWIN1256');
$query = 'INSERT INTO STUDENTS (IDNO, START_DATE) VALUES (:idno_v,
:startDate_v)';
$stid = oci_parse($conn, $query);
$idno = 999;
$startDate = date("d-M-y");
oci_bind_by_name($stid, ':idno_v', $idno);
oci_bind_by_name($stid, ':startDate_v', $startDate);
oci_execute($stid);
Expected result:
show data in STUDENTS table
Actual result:
--
no data inserted
--
Edit bug report at http://bugs.php.net/bug.php?id=51540&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51540&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51540&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51540&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51540&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51540&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51540&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51540&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51540&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51540&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51540&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51540&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51540&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51540&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51540&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51540&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51540&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51540&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51540&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51540&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51540&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51540&r=mysqlcfg
Req #51536 [Opn->Asn]: Add sapi binary location to php ini search path
Edit report at http://bugs.php.net/bug.php?id=51536&edit=1 ID: 51536 Updated by: paj...@php.net Reported by: ksin...@php.net Summary: Add sapi binary location to php ini search path -Status: Open +Status: Assigned Type: Feature/Change Request Package: *Configuration Issues Operating System: Windows PHP Version: 5.2.13 -Assigned To: +Assigned To: pajoye New Comment: hi, Yes, ini location detection is not so good right now and needs to be improved. However it has nothing to do with SxS per se. It is not need for FastCGI as one can use php-cgi.exe -c c:\phpxxx\php.ini. The installer could do that automatically, to support multiple install of the same versions (per site configuaration) or multiple install of various versions. I don't think we will and can make change this behavior in 5.2. Please note that SxS support won't be done for 5.2, trunk will have it, whatever will be this version. Previous Comments: [2010-04-12 00:06:17] ksin...@php.net Description: PHP searches php.ini in the binary location which is retrieved using GetModuleFileName (first parameter to GetModuleFileName is NULL). This will return path to current *executable* which won't be path to php sapi binary in case of dlls. For IIS, location of w3wp.exe which is %windir%\system32\inetsrv\ will be added to php ini search path. Is this intentional? Can we change this code to make it look for php.ini in the folder where php sapi binary is present? Without this fix, users running non-cgi SAPIs are required to set PHPRC environment variable or IniFilePath registry key to make PHP pick php.ini in the php install folder. If this bug is fixed, windows installer can stop setting PHPRC path to [installdir] and will be able to support side-by-side (SxS) install of PHP 5.2 and PHP 5.3. For installer to support SxS install, this change is required in PHP 5.2 and PHP 5.3. If we are worried about this being breaking change, we can just *add* php sapi binary location to php ini search path. -- Edit this bug report at http://bugs.php.net/bug.php?id=51536&edit=1
