Bug #60306 [Opn]: zend-multibyte failed in 5.4
Edit report at https://bugs.php.net/bug.php?id=60306&edit=1 ID: 60306 Updated by: larue...@php.net Reported by:larue...@php.net Summary:zend-multibyte failed in 5.4 Status: Open Type: Bug Package:mbstring related PHP Version:5.4.0RC1 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: dmitry, plz look at this, thanks :) Previous Comments: [2011-11-15 07:29:21] larue...@php.net Description: same script, same ini, 5.4 result a wrong result . Test script: --- save the test script in fenc=cp936. run: php53 -dmbstring.internal_encoding=utf8 test.php and php54 -dmbstring.internal_encoding=utf8 test.php Expected result: string(9) "æ´ªä»ç" Actual result: -- 5.3 works fine. but 5.4 output: string(3) "æ´ª" -- Edit this bug report at https://bugs.php.net/bug.php?id=60306&edit=1
[PHP-BUG] Bug #60306 [NEW]: zend-multibyte failed in 5.4
From: laruence Operating system: PHP version: 5.4.0RC1 Package: mbstring related Bug Type: Bug Bug description:zend-multibyte failed in 5.4 Description: same script, same ini, 5.4 result a wrong result . Test script: --- save the test script in fenc=cp936. run: php53 -dmbstring.internal_encoding=utf8 test.php and php54 -dmbstring.internal_encoding=utf8 test.php Expected result: string(9) "æ´ªä»ç" Actual result: -- 5.3 works fine. but 5.4 output: string(3) "æ´ª" -- Edit bug report at https://bugs.php.net/bug.php?id=60306&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60306&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60306&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60306&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60306&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60306&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60306&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60306&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60306&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60306&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60306&r=support Expected behavior: https://bugs.php.net/fix.php?id=60306&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60306&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60306&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60306&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60306&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60306&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60306&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60306&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60306&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60306&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60306&r=mysqlcfg
Req #60219 [Com]: POSTDATA periods (.) being converted to underscores (_)
Edit report at https://bugs.php.net/bug.php?id=60219&edit=1
ID: 60219
Comment by: pablitobof at yahoo dot com dot mx
Reported by:kieran at menor dot dk
Summary:POSTDATA periods (.) being converted to underscores
(_)
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
PHP 5.4 alpha1 has just been released which removes register_globals. It seems
appropriate that there would be a matching move towards removing the now
unnecessary translation of characters in requests.
Previous Comments:
[2011-11-04 14:10:02] kieran at menor dot dk
Not to mention, it's also potentially confusing and unexpected behavior for
people who didn't happen to read that tiny paragraph of the manual.
[2011-11-04 14:04:59] kieran at menor dot dk
Description:
This is documented "intended" behavior as per this section of the manual:
http://www.php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names
I'm guessing it's a leftover from back when register_globals a common thing.
It's been reported as a bug before a long time ago, and dismissed:
https://bugs.php.net/bug.php?id=30956
... but this is 2011, and I think it's worth giving it another go. Here's why:
First of all, nobody assigns POSTDATA directly to variables anymore. It all
goes through $_POST;
Secondly, the claim that you can't have periods in variable names is bogus (see
test script).
Lastly, the period is a good seperator to have available, and I understand that
certain services such as OpenID depend on it, as noted here:
http://stackoverflow.com/questions/68651/can-i-get-php-to-stop-replacing-characters-in-get-or-post-arrays#1939911
Test script:
---
${'sure.you.can'} = 'Foo';
var_dump($GLOBALS['sure.you.can']);
--
Edit this bug report at https://bugs.php.net/bug.php?id=60219&edit=1
Bug #60159 [Opn->Csd]: Router returns false, but POST is not passed to requested resource
Edit report at https://bugs.php.net/bug.php?id=60159&edit=1
ID: 60159
Updated by: larue...@php.net
Reported by:adam at sixohthree dot com
Summary:Router returns false, but POST is not passed to
requested resource
-Status: Open
+Status: Closed
Type: Bug
Package:Built-in web server
Operating System: Mac OS X 10.6.8
PHP Version:5.4.0beta2
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-11-15 03:15:10] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=319224
Log: Fixed bug #60159 (Router returns false, but POST is not passed to requested
resource) and bug #55759 (mem leak when use built-in server)
[2011-10-28 16:21:13] adam at sixohthree dot com
Description:
If the built-in web server's router returns false, and the requested resource
is a
PHP file, this PHP file will be interpreted but will not receive the same POST
data as the router. I would expect the requested resource to receive POST, for
cases when the router is only intended to handle files that do not exist (e.g.
RewriteCond's !-f). WordPress requires this behavior, though I'm sure it's not
alone.
Test script:
---
router.php:
http://localhost:8080/
array(1) {
["foo"]=>
string(3) "bar"
}
# php -S localhost:8080
# curl -d foo=bar http://localhost:8080/
array(1) {
["foo"]=>
string(3) "bar"
}
Actual result:
--
# php -S localhost:8080 router.php
# curl -d foo=bar http://localhost:8080/
array(0) {
}
# php -S localhost:8080
# curl -d foo=bar http://localhost:8080/
array(1) {
["foo"]=>
string(3) "bar"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60159&edit=1
Bug #55759 [Asn->Csd]: mem leak when use built-in server
Edit report at https://bugs.php.net/bug.php?id=55759&edit=1 ID: 55759 Updated by: larue...@php.net Reported by:larue...@php.net Summary:mem leak when use built-in server -Status: Assigned +Status: Closed Type: Bug Package:Built-in web server PHP Version:5.4.0beta1 -Assigned To:moriyoshi +Assigned To:laruence Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-11-15 03:15:11] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=319224 Log: Fixed bug #60159 (Router returns false, but POST is not passed to requested resource) and bug #55759 (mem leak when use built-in server) [2011-10-31 10:48:00] f...@php.net Cannot reproduce on Debian testing with neither beta1 nor beta2 [2011-09-25 17:08:14] fel...@php.net I can't reproduce it. [2011-09-22 03:01:20] larue...@php.net Description: router.php a.php ./php -S -t . router.php then request http://*/a.php Expected result: 11 Actual result: -- [Thu Sep 22 10:55:32 2011] 172.21.232.67:50662 [200]: /a.php [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/main/output.c(803) : Freeing 0x2A95DDB200 (88 bytes), script=- php-src/trunk/Zend/zend_alloc.c(2529) : Actual location (location was relayed) [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/main/output.c(804) : Freeing 0x2A95DDB2B0 (23 bytes), script=- [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/main/output.c(809) : Freeing 0x2A95DDB320 (8192 bytes), script=- [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/Zend/zend_stack.c(37) : Freeing 0x2A95DDD378 (512 bytes), script=- [Thu Sep 22 10:55:32 2011] Script: '-' php-src/trunk/Zend/zend_stack.c(42) : Freeing 0x2A95DDD5D0 (8 bytes), script=- -- Edit this bug report at https://bugs.php.net/bug.php?id=55759&edit=1
[PHP-BUG] Req #60305 [NEW]: myClass::unset() keyword conflict
From: Operating system: PHP version: 5.4.0RC1 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:myClass::unset() keyword conflict Description: While "keywords" and "language constructs" cannot be used as function names, I find myself with the need to have a function in my class named "unset", I also see that list is a very common and useful term. After the introduction of classes and namespaces it's time to look at enabling usage of these common terms in classes and namespaces. Test script: --- https://bugs.php.net/bug.php?id=60305&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60305&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60305&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60305&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60305&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60305&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60305&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60305&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60305&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60305&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60305&r=support Expected behavior: https://bugs.php.net/fix.php?id=60305&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60305&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60305&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60305&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60305&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60305&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60305&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60305&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60305&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60305&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60305&r=mysqlcfg
Bug #60304 [Opn->Bgs]: Can't create class function myObject::unset()
Edit report at https://bugs.php.net/bug.php?id=60304&edit=1 ID: 60304 Updated by: johan...@php.net Reported by:matty023 at gmail dot com Summary:Can't create class function myObject::unset() -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Win 7 64-bit PHP Version:5.4.0RC1 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 Keywords may not be used as identifiers. http://php.net/manual/en/reserved.keywords.php Previous Comments: [2011-11-15 01:09:39] matty023 at gmail dot com Description: There is no way to create an "unset" function in a class even if the class is in it's own namespace. This should be corrected/changed. myObject->unset() should not conflict with unset() Examples: https://bugs.php.net/bug.php?id=60304&edit=1
Bug #60252 [Com]: Signature issues with none-standard HTTP Methods
Edit report at https://bugs.php.net/bug.php?id=60252&edit=1
ID: 60252
Comment by: hubert at muchlearning dot org
Reported by:ahmad at codeinchaos dot com
Summary:Signature issues with none-standard HTTP Methods
Status: Open
Type: Bug
Package:oauth
Operating System: Ubuntu/Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Related, but not exactly the same issue: there also seems to be errors when
verifying the signature when there is more than one parameter with the same
name, or if array parameters are sent (e.g. parameters of the form
"foo[0]=bar", presumably because it is looking at $_POST instead of looking at
the raw POST data.
Previous Comments:
[2011-11-09 18:29:31] ahmad at codeinchaos dot com
Description:
I could be wrong in my understanding of oAuth 1.0a ... so I'm sorry if the
following does not apply:
the extension doesn't seem to be able to sign requests with a custom HTTP
Method
(verb) with a payload ...
ex:
curl -iH "Authorization: OAuth {PARAMS-HERE}" -d
"value1=foo&value2=foo2&value3=foo3 -X LINK http://domain.tld/api
signature always fails, because the extension does not grab the payload for
none
POST requests.
Expected result:
the oaugh signature should always use the payload body params regardless of the
HTTP Method.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60252&edit=1
[PHP-BUG] Bug #60304 [NEW]: Can't create class function myObject::unset()
From: Operating system: Win 7 64-bit PHP version: 5.4.0RC1 Package: Scripting Engine problem Bug Type: Bug Bug description:Can't create class function myObject::unset() Description: There is no way to create an "unset" function in a class even if the class is in it's own namespace. This should be corrected/changed. myObject->unset() should not conflict with unset() Examples: https://bugs.php.net/bug.php?id=60304&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60304&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60304&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60304&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60304&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60304&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60304&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60304&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60304&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60304&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60304&r=support Expected behavior: https://bugs.php.net/fix.php?id=60304&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60304&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60304&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60304&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60304&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60304&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60304&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60304&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60304&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60304&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60304&r=mysqlcfg
Bug #60278 [Opn]: BC Break + warning in array_diff with nested arrays
Edit report at https://bugs.php.net/bug.php?id=60278&edit=1
ID: 60278
Updated by: fel...@php.net
Reported by:kontakt at beberlei dot de
Summary:BC Break + warning in array_diff with nested arrays
Status: Open
Type: Bug
Package:Arrays related
PHP Version:5.4.0RC1
Block user comment: N
Private report: N
New Comment:
The difference is only the E_NOTICE message, the code behaves in the sameway.
Previous Comments:
[2011-11-12 09:55:34] kontakt at beberlei dot de
Description:
A warning occurs when you call array_diff with one nested and one flat array.
This code worked on 5.3.
Test script:
---
"id");
$b = array(0 => array("foo" => "bar"));
$d = array_diff($a, $b);
var_dump($d);
Expected result:
array(1) {
[0]=>
string(2) "id"
}
Actual result:
--
Notice: Array to string conversion in /home/benny/code/php/tests/array_diff.php
on line 6
array(1) {
[0]=>
string(2) "id"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60278&edit=1
Bug #60296 [Opn->Fbk]: Unable to convert domains valid under IDNA2008 Specification
Edit report at https://bugs.php.net/bug.php?id=60296&edit=1
ID: 60296
Updated by: paj...@php.net
Reported by:ameen at tasjeel dot ae
Summary:Unable to convert domains valid under IDNA2008
Specification
-Status: Open
+Status: Feedback
Type: Bug
Package:idn
Operating System: Fedora
PHP Version:5.3.8
Block user comment: N
Private report: N
Previous Comments:
[2011-11-14 22:55:34] paj...@php.net
I suppose you use intl's idn_to_ascii right?
In this case, this is most likely a bug in the ICU library, can you please try
to
report a bug at the icu-project.org directly. PHP only wraps ICU functions of
the
ICU library and data (unicode data). As it is supposed to implement IDNA2008 in
its latest release, it should work.
btw, which ICU version do you use?
[2011-11-14 15:09:45] ameen at tasjeel dot ae
Description:
The idn implementation in php does not seem to fully support BIDI rules as
defined in IDNA2008 specification which are the IETF RFCs 5890 - 5894. This has
been noticed because it does not seem to support converting right-to-left
script labels ending with a number, and this was addressed by these RFC's.
With the function below there is no output.
Test script:
---
echo idn_to_ascii("اختبار7.اÙ
ارات");
Expected result:
xn--7-ymcadjxy.xn--mgbaam7a8h
--
Edit this bug report at https://bugs.php.net/bug.php?id=60296&edit=1
Bug #60296 [Opn]: Unable to convert domains valid under IDNA2008 Specification
Edit report at https://bugs.php.net/bug.php?id=60296&edit=1
ID: 60296
Updated by: paj...@php.net
Reported by:ameen at tasjeel dot ae
Summary:Unable to convert domains valid under IDNA2008
Specification
Status: Open
Type: Bug
Package:idn
Operating System: Fedora
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I suppose you use intl's idn_to_ascii right?
In this case, this is most likely a bug in the ICU library, can you please try
to
report a bug at the icu-project.org directly. PHP only wraps ICU functions of
the
ICU library and data (unicode data). As it is supposed to implement IDNA2008 in
its latest release, it should work.
btw, which ICU version do you use?
Previous Comments:
[2011-11-14 15:09:45] ameen at tasjeel dot ae
Description:
The idn implementation in php does not seem to fully support BIDI rules as
defined in IDNA2008 specification which are the IETF RFCs 5890 - 5894. This has
been noticed because it does not seem to support converting right-to-left
script labels ending with a number, and this was addressed by these RFC's.
With the function below there is no output.
Test script:
---
echo idn_to_ascii("اختبار7.اÙ
ارات");
Expected result:
xn--7-ymcadjxy.xn--mgbaam7a8h
--
Edit this bug report at https://bugs.php.net/bug.php?id=60296&edit=1
Req #60302 [Opn->Asn]: DateTime::createFromFormat should new static(), not new self()
Edit report at https://bugs.php.net/bug.php?id=60302&edit=1 ID: 60302 Updated by: der...@php.net Reported by:kontakt at beberlei dot de Summary:DateTime::createFromFormat should new static(), not new self() -Status: Open +Status: Assigned Type: Feature/Change Request Package:Date/time related PHP Version:Irrelevant -Assigned To: +Assigned To:derick Block user comment: N Private report: N New Comment: Had a quick look at this, but it wasn't as simple as I thought. Needs some more investigation. Previous Comments: [2011-11-14 20:00:54] kontakt at beberlei dot de Description: I want to extend DateTime, but without DateTime::createFromFormat, actually creating instances from my class, i.e. "MyDateTime::createFromFormat" this is rather problematic. Test script: --- https://bugs.php.net/bug.php?id=60302&edit=1
[PHP-BUG] Bug #60303 [NEW]: Custom session handlers fail when using header redirect
From:
Operating system: Linux 2.6.40.4-5
PHP version: 5.3.8
Package: Session related
Bug Type: Bug
Bug description:Custom session handlers fail when using header redirect
Description:
I have a custom session handler. My session variables are not saved when I
use a header redirect. In fact, the $_SESSION array is shown as empty.
If I use the standard session handlers, everything works fine as expected.
Test script:
---
The three files for replicating this problem are can be retrieve from the
following archive:
https://globalopsccci.org/TheKey_AuthTest/testfiles.tar.bz2
Expected result:
The following output should be displayed:
testarray(1) { ["test"]=> string(4) "test" }
The above is displayed if I comment out the include_once line in test.php
and test2.php.
--
Edit bug report at https://bugs.php.net/bug.php?id=60303&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60303&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60303&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60303&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60303&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60303&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60303&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60303&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60303&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60303&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60303&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60303&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60303&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60303&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60303&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60303&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60303&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60303&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60303&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60303&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60303&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60303&r=mysqlcfg
Req #40587 [Com]: Attempt to call undefined function gives a fatal error instead of recoverable
Edit report at https://bugs.php.net/bug.php?id=40587&edit=1 ID: 40587 Comment by: matteosistisette at gmail dot com Reported by:mathiasrav at gmail dot com Summary:Attempt to call undefined function gives a fatal error instead of recoverable Status: Bogus Type: Feature/Change Request Package:Feature/Change Request Operating System: WinXP PHP Version:5.2.1 Block user comment: N Private report: N New Comment: If this is not a bug, this is a HUGE design flaw that MUST be fixed, so is there any difference? If calls to undefined functions were detected at compile time, this would be fine. But since they are detected at runtime, you simply can't debug your code from such errors if a misspelled call happens to be within an if clause. Not being able to catch these errors means not being able to debug them, which means, the language's designed is flawed. A "Fatal error: call to undefined function" SHOULD be a E_RECOVERABLE, not a E_ERROR. Anything that happens at runtime and can conceivably be recovered from, must be a E_RECOVERABLE. Previous Comments: [2007-02-21 23:20:50] der...@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 . [2007-02-21 23:06:37] mathiasrav at gmail dot com A little change to the description-section - PHP doesn't crash, it simply halts script execution. The *script* "crashes". [2007-02-21 23:03:16] mathiasrav at gmail dot com Description: If you try to call an undefined function, PHP raises an E_ERROR and crashes - not a catchable E_RECOVERABLE_ERROR. This isn't a problem for web-related scripts, but for maintainence/shell-like scripts, this can be a help. I have a script with an idle-loop that calls (includes) module-files, and if a change to one of these has a typo, all socket connections and the like are killed. Reproduce code: --- Expected result: The call to qweasd() should return false or null. If the programmer has made the script able to recover from calls to unknown functions, he must have written code that can tell the difference between the return code from a known and an unknown function. Actual result: -- The script halts. -- Edit this bug report at https://bugs.php.net/bug.php?id=40587&edit=1
[PHP-BUG] Req #60302 [NEW]: DateTime::createFromFormat should new static(), not new self()
From: Operating system: PHP version: Irrelevant Package: Date/time related Bug Type: Feature/Change Request Bug description:DateTime::createFromFormat should new static(), not new self() Description: I want to extend DateTime, but without DateTime::createFromFormat, actually creating instances from my class, i.e. "MyDateTime::createFromFormat" this is rather problematic. Test script: --- https://bugs.php.net/bug.php?id=60302&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60302&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60302&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60302&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60302&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60302&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60302&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60302&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60302&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60302&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60302&r=support Expected behavior: https://bugs.php.net/fix.php?id=60302&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60302&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60302&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60302&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60302&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60302&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60302&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60302&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60302&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60302&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60302&r=mysqlcfg
[PHP-BUG] Bug #60301 [NEW]: Can't commit in some cases
From: irker Operating system: PHP version: Irrelevant Package: Online Doc Editor problem Bug Type: Bug Bug description:Can't commit in some cases Description: In some cases users can't commit. For example: svn: '/local/web/sites/edit.php.net/data/phpdoc-all/ru/reference/network' is not a working copy In this commit user also added reference/network/functions directory. I connect to server and run "svn st" It's showed, that both direstories exists, but not under control version. I fixed it temporary by adding this direstories to svn and commit (user can commit files only after I commit directories, strange 0_o ) -- Edit bug report at https://bugs.php.net/bug.php?id=60301&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60301&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60301&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60301&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60301&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60301&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60301&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60301&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60301&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60301&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60301&r=support Expected behavior: https://bugs.php.net/fix.php?id=60301&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60301&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60301&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60301&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60301&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60301&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60301&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60301&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60301&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60301&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60301&r=mysqlcfg
[PHP-BUG] Bug #60300 [NEW]: Can't edit files in "work in progress" or "patches"
From: irker Operating system: PHP version: Irrelevant Package: Online Doc Editor problem Bug Type: Bug Bug description:Can't edit files in "work in progress" or "patches" Description: Can't edit files in "work in progress" or "patches". 1) edit file and/or move it to patch. In both cases files moved to "work" table. 2) Commit same files directly through svn. 3) Update edit.php.net svn working copy and DB files. 4) Can't edit or do something with files in "work in progress" or "patches". Only through "all files" we can cancel changes. -- Edit bug report at https://bugs.php.net/bug.php?id=60300&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60300&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60300&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60300&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60300&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60300&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60300&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60300&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60300&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60300&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60300&r=support Expected behavior: https://bugs.php.net/fix.php?id=60300&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60300&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60300&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60300&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60300&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60300&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60300&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60300&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60300&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60300&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60300&r=mysqlcfg
Bug #60298 [Com]: PHP 5.4.0RC1 - Tests failed : 2
Edit report at https://bugs.php.net/bug.php?id=60298&edit=1
ID: 60298
Comment by: fedora at famillecollet dot com
Reported by:fedora at famillecollet dot com
Summary:PHP 5.4.0RC1 - Tests failed : 2
Status: Open
Type: Bug
Package:igbinary
Operating System: GNU/Linux (Fedora 15)
PHP Version:5.4.0RC1
Block user comment: N
Private report: N
New Comment:
About igbinary_unserialize_v1_compatible, it seems related to
https://bugs.php.net/bug.php?id=55798.
I think igbinary unserialization result should be the same than PHP standard
serializer.
Linked bug is fix in 5.3 branch, so the test will also failed when this version
will be published.
Previous Comments:
[2011-11-14 17:45:56] fedora at famillecollet dot com
Description:
Tried with 1.1.1 and latest git snapshot.
Test script:
---
make test
Expected result:
Test failed : 0
Actual result:
--
=
TEST RESULT SUMMARY
-
Exts skipped:0
Exts tested : 30
-
Number of tests : 4441
Tests skipped :3 ( 6.8%)
Tests warned:0 ( 0.0%) ( 0.0%)
Tests failed:2 ( 4.5%) ( 4.9%)
Expected fail :0 ( 0.0%) ( 0.0%)
Tests passed: 39 ( 88.6%) ( 95.1%)
-
Time taken :1 seconds
=
=
FAILED TEST SUMMARY
-
Recursive objects [tests/igbinary_024.phpt]
Unserialize backwards compatible with v1.
[tests/igbinary_unserialize_v1_compatible.phpt]
=
$ cat tests/igbinary_024.diff
001+
001- objectrec
002-
17044f626a32140711026161001105002a006262001108004f626a32006363001109004f626a32006f626a17034f626a140311016106011104002a006206021106004f626a006306030e06060111016206021101630603
003- OK
004- objectrecarr
005-
17044f626a331401110a004f626a33006f626a731404060017034f626a140311016106001104002a006206001106004f626a0063060406011a0214030e0306000e0406010e05060406021a0214030e0306000e0406020e05060406031a0214030e0306000e0406030e050604
006- OK
007- objectselfrec
008- 17044f626a3414021107004f626a34006106641109004f626a34006f626a2200
009- OK
$ cat tests/igbinary_unserialize_v1_compatible.diff
001+ Differing unserialized: object
002+ Expected:
001- reference deserialization works, but the result is not a reference.
002- OK
003+ object(stdClass)#0 (4) {
004+ ["0"]=>
005+ int(1)
006+ ["1"]=>
007+ int(2)
008+ ["2"]=>
009+ int(3)
010+ ["3"]=>
011+ int(4)
012+ }
013+
014+ Actual:
015+ object(stdClass)#0 (4) {
016+ [0]=>
017+ int(1)
018+ [1]=>
019+ int(2)
020+ [2]=>
021+ int(3)
022+ [3]=>
023+ int(4)
024+ }
025+
026+ reference deserialization works, but the result is not a reference.
027+ OK
--
Edit this bug report at https://bugs.php.net/bug.php?id=60298&edit=1
[PHP-BUG] Req #60299 [NEW]: Option for hide empty patches of other users
From: irker Operating system: PHP version: Irrelevant Package: Online Doc Editor problem Bug Type: Feature/Change Request Bug description:Option for hide empty patches of other users Description: Option for hide empty patches of other users. If enable this option user see non-empty patches and all his patches. -- Edit bug report at https://bugs.php.net/bug.php?id=60299&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60299&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60299&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60299&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60299&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60299&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60299&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60299&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60299&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60299&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60299&r=support Expected behavior: https://bugs.php.net/fix.php?id=60299&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60299&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60299&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60299&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60299&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60299&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60299&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60299&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60299&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60299&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60299&r=mysqlcfg
[PHP-BUG] Bug #60298 [NEW]: PHP 5.4.0RC1 - Tests failed : 2
From:
Operating system: GNU/Linux (Fedora 15)
PHP version: 5.4.0RC1
Package: igbinary
Bug Type: Bug
Bug description:PHP 5.4.0RC1 - Tests failed : 2
Description:
Tried with 1.1.1 and latest git snapshot.
Test script:
---
make test
Expected result:
Test failed : 0
Actual result:
--
=
TEST RESULT SUMMARY
-
Exts skipped:0
Exts tested : 30
-
Number of tests : 4441
Tests skipped :3 ( 6.8%)
Tests warned:0 ( 0.0%) ( 0.0%)
Tests failed:2 ( 4.5%) ( 4.9%)
Expected fail :0 ( 0.0%) ( 0.0%)
Tests passed: 39 ( 88.6%) ( 95.1%)
-
Time taken :1 seconds
=
=
FAILED TEST SUMMARY
-
Recursive objects [tests/igbinary_024.phpt]
Unserialize backwards compatible with v1.
[tests/igbinary_unserialize_v1_compatible.phpt]
=
$ cat tests/igbinary_024.diff
001+
001- objectrec
002-
17044f626a32140711026161001105002a006262001108004f626a32006363001109004f626a32006f626a17034f626a140311016106011104002a006206021106004f626a006306030e06060111016206021101630603
003- OK
004- objectrecarr
005-
17044f626a331401110a004f626a33006f626a731404060017034f626a140311016106001104002a006206001106004f626a0063060406011a0214030e0306000e0406010e05060406021a0214030e0306000e0406020e05060406031a0214030e0306000e0406030e050604
006- OK
007- objectselfrec
008- 17044f626a3414021107004f626a34006106641109004f626a34006f626a2200
009- OK
$ cat tests/igbinary_unserialize_v1_compatible.diff
001+ Differing unserialized: object
002+ Expected:
001- reference deserialization works, but the result is not a reference.
002- OK
003+ object(stdClass)#0 (4) {
004+ ["0"]=>
005+ int(1)
006+ ["1"]=>
007+ int(2)
008+ ["2"]=>
009+ int(3)
010+ ["3"]=>
011+ int(4)
012+ }
013+
014+ Actual:
015+ object(stdClass)#0 (4) {
016+ [0]=>
017+ int(1)
018+ [1]=>
019+ int(2)
020+ [2]=>
021+ int(3)
022+ [3]=>
023+ int(4)
024+ }
025+
026+ reference deserialization works, but the result is not a reference.
027+ OK
--
Edit bug report at https://bugs.php.net/bug.php?id=60298&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60298&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60298&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60298&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60298&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60298&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60298&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60298&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60298&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60298&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60298&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60298&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60298&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60298&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60298&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60298&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60298&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60298&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60298&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60298&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60298&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60298&r=mysqlcfg
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795&edit=1
ID: 48795
Comment by: weierophin...@php.net
Reported by:gwy...@php.net
Summary:Building intl 64-bit fails on OS X
Status: Verified
Type: Bug
Package:Compile Failure
Operating System: OS X 10.5 & 10.6; Linux
PHP Version:5.3 SVN; 5.4.0RC1
Block user comment: N
Private report: N
New Comment:
I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1
on linux 64-bit.
Previous Comments:
[2011-11-11 11:30:21] ahar...@php.net
tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.
Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
"multiarch" support. Both libcurl and libicu are the normal packaged
versions.
With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:
/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
Diffing the Makefile produced by --enable-intl alone with the
"--enable-intl --with-curl" combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):
@@ -75,9 +76,9 @@
CXXFLAGS_CLEAN = -g -O2
DEBUG_CFLAGS =
EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
ZEND_EXTRA_LIBS =
INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
LFLAGS =
LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
PEAR_INSTALLDIR = ${exec_prefix}/lib/php
PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
PHP_LIBS =
OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
PHP_SAPI = none
PHP_VERSION = 5.4.0RC1
PHP_VERSION_ID = 50400
Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.
I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed "properly"
(whatever form that takes -- it may even up being an upstream issue)?
[2011-11-06 19:11:09] luke at cywh dot com
Is there going to be a proper fix for this any time soon? I'm having a lot of
trouble getting 5.3.8 to compile on OS X 10.6.8.
[2011-07-01 16:23:27] harald dot lapp at gmail dot com
just setting the EXTRA_LIBS did not work for me, but stas tip made it work.
(PHP
5.3.6, Mac OS X 10.6.7), thanks!
[2010-06-17 19:43:39] henrik at bearwoods dot dk
I have tried the above "quick-fixes" and have not been able to compile it yet.
Im on a Macbook Pro i5 and 10.6.4 (Maybe the i5 makes a difference)
[2010-05-24 21:19:51] s...@php.net
Also if you change $(CC) to $(CXX) in BUILD_* vars in Makefile it seems to help
too. Looks like if you use C++ anywhere in PHP the linker should be C++ or
library should be adde
[PHP-BUG] Bug #60297 [NEW]: Failing builds due to malformed entities.*.xml
From: nikic Operating system: PHP version: Irrelevant Package: Online Doc Editor problem Bug Type: Bug Bug description:Failing builds due to malformed entities.*.xml Description: If I do a build check on the DE translation in the online editor it will fail with this message: ERROR (file:local/web/sites/edit.php.net/data/phpdoc-all/de/reference/zip/entities.ziparchive.xml:1:2) &.local.web.sites.edit.php.net.data.phpdoc-all.de.reference.zip.ziparchive.addemptydir; --^ xmlParseEntityRef: no name Other translations are experiencing similar problems. But even though the online editor says there was a build failure it still works locally and also on http://docs.php.net/download-docs.php?sizes=1. The problem seems incorrectly generated entities.*.xml files. -- Edit bug report at https://bugs.php.net/bug.php?id=60297&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60297&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60297&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60297&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60297&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60297&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60297&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60297&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60297&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60297&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60297&r=support Expected behavior: https://bugs.php.net/fix.php?id=60297&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60297&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60297&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60297&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60297&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60297&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60297&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60297&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60297&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60297&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60297&r=mysqlcfg
[PHP-BUG] Bug #60296 [NEW]: Unable to convert domains valid under IDNA2008 Specification
From:
Operating system: Fedora
PHP version: 5.3.8
Package: idn
Bug Type: Bug
Bug description:Unable to convert domains valid under IDNA2008 Specification
Description:
The idn implementation in php does not seem to fully support BIDI rules as
defined in IDNA2008 specification which are the IETF RFCs 5890 - 5894. This
has been noticed because it does not seem to support converting
right-to-left script labels ending with a number, and this was addressed by
these RFC's.
With the function below there is no output.
Test script:
---
echo idn_to_ascii("اختبار7.اÙ
ارات");
Expected result:
xn--7-ymcadjxy.xn--mgbaam7a8h
--
Edit bug report at https://bugs.php.net/bug.php?id=60296&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60296&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60296&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60296&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60296&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60296&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60296&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60296&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60296&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60296&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60296&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60296&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60296&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60296&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60296&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60296&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60296&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60296&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60296&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60296&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60296&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60296&r=mysqlcfg
Bug #60176 [Com]: date + strtotime fails to calculate date
Edit report at https://bugs.php.net/bug.php?id=60176&edit=1
ID: 60176
Comment by: sombra2eternity at gmail dot com
Reported by:sombra2eternity at gmail dot com
Summary:date + strtotime fails to calculate date
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu
PHP Version:5.4
Block user comment: N
Private report: N
New Comment:
@fa
You are totally right. My fault, sorry for the noise.
Previous Comments:
[2011-10-31 15:45:19] f...@php.net
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which do
not suffer from DST.
You do realize that there are indeed 24h between 2011-10-30 00:00:00 and
2011-10-30 23:00:00, right?
This is when DST was adjusted.
Try your code with 2011-10-31 and you'll see 2011-11-01 as a result of adding
24h.
[2011-10-31 14:37:58] sombra2eternity at gmail dot com
I just compiled: php5.4-201110311230
---
desktop7@desktop7-desktop:~/php5.4-201110311230/sapi/cli$ ./php -v
PHP 5.4.0RC1-dev (cli) (built: Oct 31 2011 15:21:08)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
---
desktop7@desktop7-desktop:~/php5.4-201110311230/sapi/cli$ ./php
/var/www/strto.php
2011-10-30
CONTENT OF STRTO.PHP:
Thanks for helping me
[2011-10-31 14:01:32] f...@php.net
I can't reproduce this with PHP_5_3 HEAD.
Could you please check that your "date.timezone" is set correctly in your
php.ini?
It could help to compare "Y-m-d H:i:s" output.
[2011-10-31 00:20:04] sombra2eternity at gmail dot com
Description:
Dont know if corrected in new versions but I cant actually upgrade so I write
it here anyway to be sure its reported.
Strtotime/date fails to get the date in a simple test.
I think I found a bug:
echo date("Y-m-d",strtotime('2011-10-30')+86400);
//returns 2011-10-30 and should return 2011-10-31
desktop7@desktop7-desktop:~$ php -v
PHP 5.3.5-1ubuntu7.3 with Suhosin-Patch (cli) (built: Oct 13 2011 21:56:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
echo date("Y-m-d",strtotime('2011-10-30')+86400);
Expected result:
2011-10-31
Actual result:
--
2011-10-30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60176&edit=1
Bug #55219 [Com]: Segmentation fault with Serializable Object on self-reference
Edit report at https://bugs.php.net/bug.php?id=55219&edit=1
ID: 55219
Comment by: errebi at gmail dot com
Reported by:garic dot suess+php at gmail dot com
Summary:Segmentation fault with Serializable Object on
self-reference
Status: Verified
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu Linux 10.10 x64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I can reproduce it on PHP 5.2.11, but the result is quite different. (one more
itaration)
object(Test)#1 (2) {
["member"]=>
object(Test)#1 (2) {
["member"]=>
*RECURSION*
["message"]=>
string(8) "original"
}
["message"]=>
string(8) "original"
}
Segmentation fault
Hope could help
Previous Comments:
[2011-07-17 08:23:58] fel...@php.net
On 5.4 and trunk works because the r299770 change (Added support for object
references in recursive serialize() calls. FR #36424)
[2011-07-17 07:48:36] fel...@php.net
I can reproduce it only in 5.3 branch. It's due a stack call overflow.
[2011-07-16 23:46:29] garic dot suess+php at gmail dot com
Description:
---
>From manual page: http://www.php.net/class.serializable
---
When a Serializable object contains a reference to it self a Segmentation fault
is caused.
I first encountered this in 5.3.3, then found a binary package for 5.3.5 for my
distribution. Finally I compiled my own 5.3.6. The segmentation fault persists
in
all three versions.
If the Serializable interface is removed the code works fine.
Although the fault is reproducible, I found encountered other self-reference
scenarios where it is not triggered, making this very unpredictable.
Test script:
---
class Test implements Serializable {
public $member, $message;
function __construct($message) {
$this->message = $message;
}
function serialize() {
return serialize(array($this->message, $this->member));
}
function unserialize($serialized) {
list($this->message, $this->member) = unserialize($serialized);
}
}
$constructed = new Test("original");
$constructed->member = $constructed; //References to self (in this example
pointless, but technically legal)
var_dump($constructed);
$transported = unserialize(serialize($constructed)); // Segmentation fault.
Expected result:
Clean exit..
Actual result:
--
object(Test)#1 (2) {
["member"]=>
*RECURSION*
["message"]=>
string(8) "original"
}
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55219&edit=1
Bug #41540 [Com]: A probable solution for the Mysterious Warning Message.
Edit report at https://bugs.php.net/bug.php?id=41540&edit=1 ID: 41540 Comment by: claudio dot galdiolo at gmail dot com Reported by:essem76 at yahoo dot com Summary:A probable solution for the Mysterious Warning Message. Status: Bogus Type: Bug Package:Session related Operating System: Windows Server 2000 PHP Version:5.2.2 Block user comment: N Private report: N New Comment: I disabled the warning adding these lines to my .htaccess (read http://www.php.net/manual/en/configuration.changes.php). php_value session.bug_compat_42 "0" php_value session.bug_compat_warn "0" Previous Comments: [2010-12-13 20:08:01] jaguilar at addax dot cc Hi, I had the same problem, and in my case it was here $arrFormData and here $_SESSION['arrFormData'] The thing is having the same variable name. In my case it happened on a $_GET array, but I guess it should be similar. Give it a try on renaming the $arrFormData variable to something else and let us know if it worked. [2010-11-06 19:07:42] scrivimi at mosconimatteo dot com Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively in Unknown on line 0 i'm only 14. i don't understand it [2010-11-06 19:07:42] scrivimi at mosconimatteo dot com Warning: Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively in Unknown on line 0 i'm only 14. i don't understand it [2007-06-01 06:43:19] tony2...@php.net http://php.net/session Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. *You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively.* [2007-06-01 06:14:15] essem76 at yahoo dot com Here is the stripped down code generating the same problem.. So please discard all the previous and consider only this. First Name: Last Name: The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=41540 -- Edit this bug report at https://bugs.php.net/bug.php?id=41540&edit=1
[PHP-BUG] Bug #60295 [NEW]: bcompiler doesn't remove PHPDoc comments
From:
Operating system: Ubuntu
PHP version: 5.3.8
Package: bcompiler
Bug Type: Bug
Bug description:bcompiler doesn't remove PHPDoc comments
Description:
Output files include PHPDoc comments (/** Comments */) which are not meant
to be
there. This makes running the file fail at runtime.
Other comments are removed correctly.
Test script:
---
foo.php:
/**
* Foo
*
* A sample file - this comment will break the output
*/
//This comment will be removed
echo 'FooBar';
bar.php:
$fh = fopen('o.phb', 'w');
bcompiler_write_header($fh);
bcompiler_write_file($fh, 'foo.php');
bcompiler_write_footer($fh);
fclose($fh);
include 'o.phb';
Expected result:
FooBar
Actual result:
--
Failure. No error shown.
--
Edit bug report at https://bugs.php.net/bug.php?id=60295&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60295&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60295&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60295&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60295&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60295&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60295&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60295&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60295&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60295&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60295&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60295&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60295&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60295&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60295&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60295&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60295&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60295&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60295&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60295&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60295&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60295&r=mysqlcfg
Bug #60294 [Opn->Bgs]: Strange "strict notice" for overrided simplexml class from external file
Edit report at https://bugs.php.net/bug.php?id=60294&edit=1 ID: 60294 Updated by: larue...@php.net Reported by:miracle at rpz dot name Summary:Strange "strict notice" for overrided simplexml class from external file -Status: Open +Status: Bogus Type: Bug Package:SimpleXML related Operating System: Linux PHP Version:5.3.8 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 a new feature of such warning improvement has been introduced in 5.4, run the test script in 5.4 will find the reason: PHP Strict Standards: Declaration of FailTest::addAttribute() should be compatible with SimpleXMLElement::addAttribute($name, $value = NULL, $ns = NULL) in /tmp/failtest-hA9N4B on line 4 Previous Comments: [2011-11-14 13:14:00] miracle at rpz dot name Description: Extended class compatible if declared in same file and "not compatible" if included from external script. Test script: --- https://bugs.php.net/bug.php?id=60294&edit=1
[PHP-BUG] Bug #60294 [NEW]: Strange "strict notice" for overrided simplexml class from external file
From: Operating system: Linux PHP version: 5.3.8 Package: SimpleXML related Bug Type: Bug Bug description:Strange "strict notice" for overrided simplexml class from external file Description: Extended class compatible if declared in same file and "not compatible" if included from external script. Test script: --- https://bugs.php.net/bug.php?id=60294&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60294&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60294&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60294&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60294&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60294&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60294&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60294&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60294&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60294&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60294&r=support Expected behavior: https://bugs.php.net/fix.php?id=60294&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60294&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60294&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60294&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60294&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60294&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60294&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60294&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60294&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60294&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60294&r=mysqlcfg
[PHP-BUG] Bug #60293 [NEW]: svn_import need log meesage
From:
Operating system: Unix
PHP version: Irrelevant
Package: svn
Bug Type: Bug
Bug description:svn_import need log meesage
Description:
The svn_import do nothing when I use it. I saw a bugfix on svn_make that
needed
also a log message to work, so I try to use the same fix on svn_import,
recompiling the source and it worked.
I also had to correct the type of the variable nonrecursive from
svn_boolean_t
to zend_bool to make the recursion work.
This is my corrected source code:
/* {{{ proto bool svn_import(string path, string url, bool nonrecursive [,
string message ])
Imports unversioned path into repository at url */
PHP_FUNCTION(svn_import)
{
svn_client_commit_info_t *commit_info_p = NULL;
const char *path = NULL, *logmsg = NULL;
const char *utf8_path = NULL;
int pathlen, logmsg_len;
char *url;
int urllen;
zend_bool nonrecursive;
svn_error_t *err;
apr_pool_t *subpool;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssb|s",
&path, &pathlen, &url, &urllen, &nonrecursive,
&logmsg, &logmsg_len)) {
RETURN_FALSE;
}
PHP_SVN_INIT_CLIENT();
subpool = svn_pool_create(SVN_G(pool));
if (!subpool) {
RETURN_FALSE;
}
svn_utf_cstring_to_utf8 (&utf8_path, path, subpool);
path = svn_path_canonicalize(utf8_path, subpool);
SVN_G(ctx)->log_msg_baton = logmsg;
err = svn_client_import(&commit_info_p, path, url, nonrecursive,
SVN_G(ctx), subpool);
SVN_G(ctx)->log_msg_baton = NULL;
if (err) {
php_svn_handle_error (err TSRMLS_CC);
RETVAL_FALSE;
} else {
RETVAL_TRUE;
}
svn_pool_destroy(subpool);
}
Test script:
---
svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME,
$login);
svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_PASSWORD,
$passwd);
svn_auth_set_parameter(PHP_SVN_AUTH_PARAM_IGNORE_SSL_VERIFY_ERRORS, true);
svn_auth_set_parameter(SVN_AUTH_PARAM_NON_INTERACTIVE, true);
svn_auth_set_parameter(SVN_AUTH_PARAM_NO_AUTH_CACHE,true);
try
{
if (false === svn_ls($repo_dest))
{
// Import recursively a folder containing files & sub-folders
if (false === svn_import($path_src, $repo_dest, false))
throw new Exception("Can't import...");
}
}
catch (Exception $e)
{
}
Expected result:
I expect to have the source directory recursively imported to the SVN.
Actual result:
--
Nothing is done.
With my first fix (i.e. adding new parameter for log message) only the
first
level of the source directory content is imported (the recursivity does not
work).
With my second fix (i.e. changing the type of the variable "nonrecursive")
the
source directory is completly imported (the recursivity now works).
--
Edit bug report at https://bugs.php.net/bug.php?id=60293&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60293&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60293&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60293&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60293&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60293&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60293&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60293&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60293&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60293&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60293&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60293&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60293&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60293&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60293&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60293&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60293&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60293&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60293&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60293&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60293&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60293&r=mysqlcfg
Req #60289 [Opn->Bgs]: SSL Issue
Edit report at https://bugs.php.net/bug.php?id=60289&edit=1 ID: 60289 Updated by: johan...@php.net Reported by:arv_php at yahoo dot com Summary:SSL Issue -Status: Open +Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: any PHP Version:5.3.8 Block user comment: N Private report: N New Comment: PHP knows nothing about that. Many web servers will set $_SERVER['HTTPS'] to the value "on" when HTTPS is used, though. Previous Comments: [2011-11-14 05:33:10] arv_php at yahoo dot com Description: Its very surprising that we don't have any function or Super Global variable to tell us whether my current page URL is HTTP or HTTPS. For this we are still rely on server port to determine HTTP or HTTPS. but if both HTTP and HTTPS are running on same port (Let 80) then, No Idea how to determine that. I just want to suggest that there must be a Super Global variable or function to fetch Complete current URL including HTTP/ HTTPS as java script provides. I hope you all understand this concern and will provide some solution for that in next release. Test script: --- Its very surprising that we don't have any function or Super Global variable to tell us whether my current page URL is HTTP or HTTPS. For this we are still rely on server port to determine HTTP or HTTPS. but if both HTTP and HTTPS are running on same port (Let 80) then, No Idea how to determine that. I just want to suggest that there must be a Super Global variable or function to fetch Complete current URL including HTTP/ HTTPS as java script provides. I hope you all understand this concern and will provide some solution for that in next release. -- Edit this bug report at https://bugs.php.net/bug.php?id=60289&edit=1
[PHP-BUG] Bug #60292 [NEW]: System checks for available hashes
From: Operating system: Linux PHP version: 5.3.8 Package: hash related Bug Type: Bug Bug description:System checks for available hashes Description: Hi, while trying to build php that uses system's crypt(), I had to change ext/standard/config.m4 a little bit, see patch I enclosed. Expected result: php using system's crypt() when it provides all algorithms as php's implementation (as http://php.net/manual/en/function.crypt.php says). -- Edit bug report at https://bugs.php.net/bug.php?id=60292&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60292&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60292&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60292&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60292&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60292&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60292&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60292&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60292&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60292&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60292&r=support Expected behavior: https://bugs.php.net/fix.php?id=60292&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60292&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60292&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60292&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60292&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60292&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60292&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60292&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60292&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60292&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60292&r=mysqlcfg
Bug #44686 [NoF->Csd]: SOAP-ERROR: Parsing WSDL
Edit report at https://bugs.php.net/bug.php?id=44686&edit=1 ID: 44686 Updated by: dmi...@php.net Reported by:dmittner at llnw dot com Summary:SOAP-ERROR: Parsing WSDL -Status: No Feedback +Status: Closed Type: Bug Package:SOAP related Operating System: Gentoo PHP Version:5.2.5 Assigned To:dmitry Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-11-14 08:42:51] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=319151 Log: Fixed bug #44686 (SOAP-ERROR: Parsing WSDL with references) [2011-08-15 18:36:57] jeremy at techtrav dot com Also experiencing the issue with PHP 5.3 using the OTA ( Open Travel Alliance ) WSDL. Honestly if this has been an issue since 5.0.5, it should be fixed by now. Adding name="name" in front of ref=" in all of the XSD's allows the parser to succeed but it technically is an invalid WSDL. I hope there is a real fix for this glaring WSDL parsing bug soon. [2011-07-04 10:27:09] felix at hexon dot cx Im am experiencing the same problem with a .NET webservice using the 'ref' attribute in the WSDL. PHP version 5.3.6 [2010-12-02 10:09:21] norberto dot ostallo at qualitygroup dot it I'm having the same problem consuming OTA (Open Travel Alliance) XML files, using php5.3.3 on Ubuntu. Does anyone know a fix or a workaround? [2010-11-10 11:29:07] php at leentje dot org Also not working in php5.3 it seems. Why is this bug not being picked up? It kind of defeats the purpose if I have to store WSDL files locally... and even worse, also have to change/add name= to the file. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=44686 -- Edit this bug report at https://bugs.php.net/bug.php?id=44686&edit=1
Bug #60291 [Opn->Bgs]: Ltrim and Rtrim string contain number bug
Edit report at https://bugs.php.net/bug.php?id=60291&edit=1
ID: 60291
Updated by: larue...@php.net
Reported by:ekoisa at gmail dot com
Summary:Ltrim and Rtrim string contain number bug
-Status: Open
+Status: Bogus
Type: Bug
Package:Strings related
Operating System: Linux
PHP Version:5.3.8
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
the sencode of the ?trim is a list. not a pattern.
Previous Comments:
[2011-11-14 07:57:51] ekoisa at gmail dot com
Description:
strip string result for string contain numeric value not true;
this below code show it.
Test script:
---
echo "test ltrim: 05039 ";
echo ltrim("05039", "05");
echo "test rtrim: 345030 ";
echo rtrim("345030", "30");
Expected result:
test ltrim: 05039
039
test rtrim: 345030
3450
Actual result:
--
test ltrim: 05039
39
test rtrim: 345030
345
--
Edit this bug report at https://bugs.php.net/bug.php?id=60291&edit=1
