Bug #63520 [Com]: JSON extension includes a problematic license statement
Edit report at https://bugs.php.net/bug.php?id=63520&edit=1 ID: 63520 Comment by: ond...@php.net Reported by:kaplan at debian dot org Summary:JSON extension includes a problematic license statement Status: Assigned Type: Bug Package:JSON related PHP Version:Irrelevant Assigned To:remi Block user comment: N Private report: N New Comment: Stas: Of course it's a PHP bug. PHP don't live in a vacuum, but has thriving ecosystem of various users/packagers/distributors/distributions/etc. and they are all affected by the choice you (as PHP) make. It's not healthy to dug the head into the sand and pretend that it's not a _PHP_ bug, since it affects the users of PHP. Previous Comments: [2013-08-22 22:01:39] kap...@php.net Stas: We (PHP) provide the code, and the eco system clearly has a problem with it. We could either keep ignoring it while they provide a replacement code, or adopt it officially to make everyone happy. [2013-08-22 21:52:19] shitty at gmail dot com Not evil???... come on!!! [2013-08-21 18:47:57] s...@php.net How this is a PHP bug? [2013-07-17 15:18:33] r...@php.net @seld Mandriva/Fedora/Debian have drop json non-free extension but provides jsonc dropin alternative (php5-json 1.3.1 for debian). So, your comment is not PHP related. See debian packager to have this package installed when needed (pulled by main php package for Fedora). [2013-07-17 14:24:32] s...@php.net What's the status here Remi? Can we have a regular Debian release including the JSON ext before this hits testing/stable? We had a first issue on Composer today because someone was missing the json ext [1], using Ubuntu 13.10. If this isn't resolved soon Ubuntu's next release won't have json enabled by default and we'll have a support shitstorm on our hands, so please don't do Evil because of a dubious license statement. Given the prevalence of JSON APIs and such these days, it's not just Composer that will be affected, so removing it before having a replacement in place was really an unhelpful decision IMO. [1] https://github.com/composer/composer/issues/2092 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=63520 -- Edit this bug report at https://bugs.php.net/bug.php?id=63520&edit=1
[PHP-BUG] Bug #65568 [NEW]: parse_ini_file() and INI_SCANNER_RAW breaks with newlines
From: kristo at waher dot net
Operating system: Windows 7
PHP version: 5.5.3
Package: Strings related
Bug Type: Bug
Bug description:parse_ini_file() and INI_SCANNER_RAW breaks with newlines
Description:
parse_ini_file() works correctly if INI_SCANNER_RAW is not used. However
once it
is used then newlines throw errors in code and make it impossible to store
any
newline-including strings in INI files.
It's said that if you want to use newlines in your INI, you must enclose in
double-quotes. This is true, but not if you use INI_SCANNER_RAW option.
Since the alternative of not using INI_SCANNER_RAW is not an option (due to
how it
converts some strings and values), this is a bug and should be fixed.
Test script:
---
INI:
name="thomas
moore";
SCRIPT:
parse_ini_file('test.ini',false,INI_SCANNER_RAW);
Expected result:
no error
Actual result:
--
Warning: syntax error, unexpected '"' in test.ini on line 2
in \test.php on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=65568&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65568&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65568&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65568&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65568&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65568&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65568&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65568&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65568&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65568&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65568&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65568&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65568&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65568&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65568&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65568&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65568&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65568&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65568&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65568&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65568&r=mysqlcfg
Bug #65548 [Com]: Comparison for DateTimeImmutable doesn't work
Edit report at https://bugs.php.net/bug.php?id=65548&edit=1
ID: 65548
Comment by: cmbecker69 at gmx dot de
Reported by:mail at roland-ramthun dot de
Summary:Comparison for DateTimeImmutable doesn't work
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
It seems that the comparison operators are not overloaded for
DateTimeImmutable objects. Apparently they show the same behavior
as for arbitrary user defined classes.
If my assumption is correct, instead of adding a special treatment
for the comparison operators wrt. DateTimeImmutable objects, it
might be considered to add a magic method __compare(). However,
I'm not sure, if this fits well with type juggling.
Previous Comments:
[2013-08-25 14:03:21] mail at roland-ramthun dot de
Description:
Comparison for DateTimeImmutable doesn't work. The same example with DateTime
objects works.
Test script:
---
$a = new DateTimeImmutable('today');
$b = new DateTimeImmutable('tomorrow');
if ($a < $b) {
print("yay");
}
Expected result:
yay
Actual result:
--
no output
--
Edit this bug report at https://bugs.php.net/bug.php?id=65548&edit=1
Bug #65562 [Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562&edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Adam, well usually we won't need such an test function as usually we only accept things reproducable with core PHP a bug, so this report is no PHP bug. The primary purpose of the debug function here would be to allow verifying this issue was fixed (if rrh confirms this is the actual issue, I might have overseen some other issue). As I define this as not a PHP bug per se I agreee with Niki that we simply might not add an test to our test suite (currently this would be relevant only in an edge case for a commercial extension, due to the kind of error and PHP's gc also of low severity) but I wanted to discuss the requirements in case somebody picks this bug up. (and it's not one of, we already have leak() and two or so other debug only functions already) Anyways, the time spent on discussing this might have been more than needed to fix&test this, so I'll shut up unless anybody wants my review or I have some time&mood while sitting on a machine with a PHP tree. ;-) Previous Comments: [2013-08-27 20:06:55] ahar...@php.net With my doc hat on, I'm personally not too concerned if we have a debug build only function â we can cross that bridge when we get to it, and I don't think anyone relies particularly heavily on the prototype extraction scripts anyway. With my php-src hat on, would it be better to consider adding a debug extension (say ext/debug) that wraps ZE functions where appropriate so we can start writing PHPT tests for them, rather than doing this as a one off? [2013-08-27 09:42:17] ni...@php.net @johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill. [2013-08-26 23:15:59] johan...@php.net A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562&edit=1
Bug #65562 [Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562&edit=1 ID: 65562 Updated by: ahar...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: With my doc hat on, I'm personally not too concerned if we have a debug build only function â we can cross that bridge when we get to it, and I don't think anyone relies particularly heavily on the prototype extraction scripts anyway. With my php-src hat on, would it be better to consider adding a debug extension (say ext/debug) that wraps ZE functions where appropriate so we can start writing PHPT tests for them, rather than doing this as a one off? Previous Comments: [2013-08-27 09:42:17] ni...@php.net @johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill. [2013-08-26 23:15:59] johan...@php.net A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562&edit=1
Bug #65557 [Com]: Constants from Core are not defined with inline scripts
Edit report at https://bugs.php.net/bug.php?id=65557&edit=1
ID: 65557
Comment by: Laurent dot Lyaudet at gmail dot com
Reported by:Laurent dot Lyaudet at gmail dot com
Summary:Constants from Core are not defined with inline
scripts
Status: Verified
Type: Bug
Package:CGI/CLI related
Operating System: Linux
PHP Version:5.4 and later
Block user comment: N
Private report: N
New Comment:
Hi,
I thought that maybe we can alter the comportment of #php
You first type your script in the shell
Ctrl+D -> you're still running php; STDIN, STDERR, etc. are initialized for the
script
additional input provided to the script
Ctrl+D -> end of input to the script
I don't know if the shell enables this.
Moreover, it would require two Ctrl+D for users with no intent to give
additional input.
Let me know what you think about it.
Best regards,
Laurent
Previous Comments:
[2013-08-26 10:20:38] johan...@php.net
This is done by purpose: We can't easily provide STDIN as that's bound to the
script input and we either provide all three (STDIN, STDOUT, STERR) or none.
Maybe this can be improved to rebind STDIN (and then providing all three) after
the full script has been passed.
Maybe this trinity can be relaxed.
This requires some more analysis of the consequences.
[2013-08-26 09:09:30] yohg...@php.net
[yohgaki@dev PHP-5.5]$ echo '' > test
#php test
works.
Is is somehow surprising since I would have thought that the only difference
between "php test" and "php " was the input
stream for php code.
[2013-08-26 08:49:43] Laurent dot Lyaudet at gmail dot com
Description:
Hi,
I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli)
(latest debian package for current stable).
The constant STDERR is not defined for inline scripts.
I mean it isn't defined when you type #php and then you type , Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.
I didn't tested it but I assume it is not specifically STDERR which is impacted.
It is probably the same for all Core constants.
Best regards,
Laurent Lyaudet
Test script:
---
php -r 'fwrite(STDERR, "stderr\n");'
works but
root@wheezyDEVLaurent:~# php
doesn't.
Expected result:
stderr
Actual result:
--
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
Call Stack:
10.9477 215280 1. {main}() -:0
PHP Warning: fwrite() expects parameter 1 to be resource, string given in - on
line 3
PHP Stack trace:
PHP 1. {main}() -:0
PHP 2. fwrite() -:3
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
3
Call Stack:
10.9477 215280 1. {main}() -:0
10.9479 216048 2. fwrite() -:3
--
Edit this bug report at https://bugs.php.net/bug.php?id=65557&edit=1
Bug #65561 [Com]: Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4
Edit report at https://bugs.php.net/bug.php?id=65561&edit=1 ID: 65561 Comment by: Terry at ellisons dot org dot uk Reported by:craig dot mohrman at oracle dot com Summary:Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4 Status: Open Type: Bug Package:opcache Operating System: Solaris 11 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: OK, I have got this as a repeatable bug on PHP 5.3.27 with OPcache installed on a std 32bit GCC LAMP VM -- if I force the dropping of the __alignof__ defines to default to sizeof (as happens configuring with the Solaris C compiler). The minimum test that fails is $ php -d zend_extension=../modules/opcache.so -d opcache.enable=1 -d opcache.enable_cli=1 = 2) #define ZEND_MM_ALIGNMENT (__alignof__ (mm_align_test)) #else #define ZEND_MM_ALIGNMENT (sizeof(mm_align_test)) #endif whereas zend_shared_alloc.h instead sets its own PLATFORM_ALIGNMENT instead of using ZEND_MM_ALIGNMENT: #if ZEND_GCC_VERSION >= 2000 # define PLATFORM_ALIGNMENT (__alignof__ (align_test)) #else # define PLATFORM_ALIGNMENT (sizeof(align_test)) #endif However, I'll try a 32-bit 5.3.27 on a LAMP stack and force this to see if I can track it down. PS for Craig: (i) Does the Solaris compiler have a pragma/builtin equivalent to __alignof__, and what is the correct constant to use to test for the Solaris C compiler? [2013-08-26 19:43:12] craig dot mohrman at oracle dot com Description: This is a place holder bug for anyone working with Solaris and php 5.3.27 I haven't tried the latest version of PHP so maybe this just goes away. I've documented this in a thread here: https://github.com/zendtech/ZendOptimizerPlus/issues/122 But the problem appears to be in php itself. This is compiling the Zend Opcache 7.0.2 from: http://pecl.php.net/package/ZendOpcache When compiling ZendOpcache with php 5.3.27 on Solaris 11 x86 with the Solaris Studio compiler (12.1) I'm seeing Overflown errors even with the most trivial of php programs. This is all being done in 32-bit. Sparc has no such issue. Works out of the box. As a workaround I'm patching ZEND_MM_ALIGNMENT: #define ZEND_MM_ALIGNMENT 8 #define ZEND_MM_ALIGNMENT_LOG2 3 to #define ZEND_MM_ALIGNMENT 4 #define ZEND_MM_ALIGNMENT_LOG2 2 over in PHP/Zend/Zend.m4 and everything works fine. I got this 4 when compiling php 5.3.27 with gcc 4.5. That comes up with ZEND_MM_ALIGNMENT=4 but when compiling with Solaris Studio I get ZEND_MM_ALIGNMENT=8. Oddly on Solaris sparc both Solaris Studio and gcc 4.5 come up with: ZEND_MM_ALIGNMENT=8 but that works fine. So see the actual patch below. This is not the solution but gets Zend Opcache working on Solaris x86. Test script: --- $ cat simple.php "; ?> Expected result: $ php -v PHP 5.3.27 (cli) (built: Aug 20 2013 11:05:05) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.2.0, Copyright (c) 2002-2012, by Derick Rethans with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH $ php -f simple.php y = 6 Actual result: -- $ php -f simple.php File /home/cmohrman/Public/PHP/simple.php func m_x_plus_b Block: 0-5 (6) unused Block: 6-6 (1) T0: 0 T1: 0 Opt Block: 0-5 (6) T0: 0 T1: 0 Opt Block: 0-5 (6) T0: 0 T1: 0 Opt Block: 0-5 (6) T0: 0 T1: 0 Out Block: 0-5 (6) File /home/cmohrman/Public/PHP/simple.php func main Block: 0-11 (12) unused T0: 0 T1: 0 T2: 0 T3: 0 T4: 0 T5: 0 [Fri Aug 9 11:10:45 2013] Script: '/home/cmohrman/Public/PHP/simple.php' --- ./Optimizer/block_pass.c(2053) : Block 0x0935e970 status: Beginning: OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes) Start: OK End: Overflown (magic=0x instead of 0x530646BC) 1 byte(s) overflown --- Opt Block: 0-11 (12) [Fri Aug 9 11:10:45 2013] Script: '/home/cmohrman/Public/PHP/simple.php' --- ./Optimizer/block_pass.c(1220) : Block 0x0935fa70 status: Beginning: OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes) Start: OK End: Overflown (magic=0xFFB4 instead of 0x530646BC) At least 4 bytes overflown --- T0: 0 T1: 0 T2: 0 T3: 0 T4: 0 T5: 0 [Fri Aug 9 11:10:45 2013] Script: '/home/cmohrman/Public/PHP/simple.php' --- ./Optimizer/block_pass.c(2053) : Block 0x0935e9a8 status: Beginning: OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes) Start: OK End: Overflown (magic=0x instead of 0x530646BC)
Bug #65565 [Com]: var_dump of DOM objects displays empty objects
Edit report at https://bugs.php.net/bug.php?id=65565&edit=1
ID: 65565
Comment by: Laurent dot Lyaudet at gmail dot com
Reported by:Laurent dot Lyaudet at gmail dot com
Summary:var_dump of DOM objects displays empty objects
Status: Open
Type: Bug
Package:DOM XML related
Operating System: Debian Linux
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
Note that the use of Reflection doesn't yield the content either.
Some methods are listed but no property is.
Example:
ReflectionObject::export($oMyDOMObject);
Previous Comments:
[2013-08-27 16:16:34] Laurent dot Lyaudet at gmail dot com
Description:
Hi,
If you var_dump a DOMElement, a DOMNodeList, etc. you have an empty object
displayed like that :
DOMElement#130 (0) {
}
Best regards,
Laurent Lyaudet
--
Edit this bug report at https://bugs.php.net/bug.php?id=65565&edit=1
[PHP-BUG] Bug #65565 [NEW]: var_dump of DOM objects displays empty objects
From: Laurent dot Lyaudet at gmail dot com
Operating system: Debian Linux
PHP version: 5.4.19
Package: DOM XML related
Bug Type: Bug
Bug description:var_dump of DOM objects displays empty objects
Description:
Hi,
If you var_dump a DOMElement, a DOMNodeList, etc. you have an empty object
displayed like that :
DOMElement#130 (0) {
}
Best regards,
Laurent Lyaudet
--
Edit bug report at https://bugs.php.net/bug.php?id=65565&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65565&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65565&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65565&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65565&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65565&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65565&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65565&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65565&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65565&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65565&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65565&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65565&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65565&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65565&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65565&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65565&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65565&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65565&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65565&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65565&r=mysqlcfg
Bug #65561 [Com]: Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4
Edit report at https://bugs.php.net/bug.php?id=65561&edit=1 ID: 65561 Comment by: Terry at ellisons dot org dot uk Reported by:craig dot mohrman at oracle dot com Summary:Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4 Status: Open Type: Bug Package:opcache Operating System: Solaris 11 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The issue relates to the use of compiler-specific alignment directives in configure and in both the Zend and OPcache code. (The whole standardisation of platform variants isn't consistent across the code, and I suspect some code paths have only been properly exercised for the gcc and vc compilers), For example, Zend uses ZEND_MM_ALIGNMENT which is configured at the step "checking for MM alignment and log values... " based on the following check: #if (defined (__GNUC__) && __GNUC__ >= 2) #define ZEND_MM_ALIGNMENT (__alignof__ (mm_align_test)) #else #define ZEND_MM_ALIGNMENT (sizeof(mm_align_test)) #endif whereas zend_shared_alloc.h instead sets its own PLATFORM_ALIGNMENT instead of using ZEND_MM_ALIGNMENT: #if ZEND_GCC_VERSION >= 2000 # define PLATFORM_ALIGNMENT (__alignof__ (align_test)) #else # define PLATFORM_ALIGNMENT (sizeof(align_test)) #endif However, I'll try a 32-bit 5.3.27 on a LAMP stack and force this to see if I can track it down. PS for Craig: (i) Does the Solaris compiler have a pragma/builtin equivalent to __alignof__, and what is the correct constant to use to test for the Solaris C compiler? Previous Comments: [2013-08-26 19:43:12] craig dot mohrman at oracle dot com Description: This is a place holder bug for anyone working with Solaris and php 5.3.27 I haven't tried the latest version of PHP so maybe this just goes away. I've documented this in a thread here: https://github.com/zendtech/ZendOptimizerPlus/issues/122 But the problem appears to be in php itself. This is compiling the Zend Opcache 7.0.2 from: http://pecl.php.net/package/ZendOpcache When compiling ZendOpcache with php 5.3.27 on Solaris 11 x86 with the Solaris Studio compiler (12.1) I'm seeing Overflown errors even with the most trivial of php programs. This is all being done in 32-bit. Sparc has no such issue. Works out of the box. As a workaround I'm patching ZEND_MM_ALIGNMENT: #define ZEND_MM_ALIGNMENT 8 #define ZEND_MM_ALIGNMENT_LOG2 3 to #define ZEND_MM_ALIGNMENT 4 #define ZEND_MM_ALIGNMENT_LOG2 2 over in PHP/Zend/Zend.m4 and everything works fine. I got this 4 when compiling php 5.3.27 with gcc 4.5. That comes up with ZEND_MM_ALIGNMENT=4 but when compiling with Solaris Studio I get ZEND_MM_ALIGNMENT=8. Oddly on Solaris sparc both Solaris Studio and gcc 4.5 come up with: ZEND_MM_ALIGNMENT=8 but that works fine. So see the actual patch below. This is not the solution but gets Zend Opcache working on Solaris x86. Test script: --- $ cat simple.php "; ?> Expected result: $ php -v PHP 5.3.27 (cli) (built: Aug 20 2013 11:05:05) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.2.0, Copyright (c) 2002-2012, by Derick Rethans with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH $ php -f simple.php y = 6 Actual result: -- $ php -f simple.php File /home/cmohrman/Public/PHP/simple.php func m_x_plus_b Block: 0-5 (6) unused Block: 6-6 (1) T0: 0 T1: 0 Opt Block: 0-5 (6) T0: 0 T1: 0 Opt Block: 0-5 (6) T0: 0 T1: 0 Opt Block: 0-5 (6) T0: 0 T1: 0 Out Block: 0-5 (6) File /home/cmohrman/Public/PHP/simple.php func main Block: 0-11 (12) unused T0: 0 T1: 0 T2: 0 T3: 0 T4: 0 T5: 0 [Fri Aug 9 11:10:45 2013] Script: '/home/cmohrman/Public/PHP/simple.php' --- ./Optimizer/block_pass.c(2053) : Block 0x0935e970 status: Beginning: OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes) Start: OK End: Overflown (magic=0x instead of 0x530646BC) 1 byte(s) overflown --- Opt Block: 0-11 (12) [Fri Aug 9 11:10:45 2013] Script: '/home/cmohrman/Public/PHP/simple.php' --- ./Optimizer/block_pass.c(1220) : Block 0x0935fa70 status: Beginning: OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes) Start: OK End: Overflown (magic=0xFFB4 instead of 0x530646BC) At least 4 bytes overflown --- T0: 0 T1: 0 T2: 0 T3: 0 T4: 0 T5: 0 [Fri Aug 9 11:10:45 2013] Script: '/home/cmohrman/Public/PHP/simple.php' --- ./Optimizer/block_pass.c(2053) : Block 0x0935e9a8 status: Beginning
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1 ID: 61759 Comment by: contact at jubianchi dot fr Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: Also agree with the fact that the leading backslashes are redundant but the point is that class_alias returns a value saying all went fine (bool(true)) when the alias is not reachable after the call. Previous Comments: [2013-08-27 12:10:10] ni...@php.net I'm not convinced that allowing a leading \ is something we should strive towards. The \ is unnecessary and redundant (as string names are always fully qualified). I'd rather allow only the canonical form. [2013-08-27 12:04:43] jpa...@php.net Yep, let's start finding all places where classes as strings can be used, and patch them all to use zend_lookup_class(). There shouldn't be tons of them AFAIR. [2013-08-27 10:19:53] contact at jubianchi dot fr I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not "fixed" I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813 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=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1 ID: 61759 Comment by: ni...@php.net Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: I'm not convinced that allowing a leading \ is something we should strive towards. The \ is unnecessary and redundant (as string names are always fully qualified). I'd rather allow only the canonical form. Previous Comments: [2013-08-27 12:04:43] jpa...@php.net Yep, let's start finding all places where classes as strings can be used, and patch them all to use zend_lookup_class(). There shouldn't be tons of them AFAIR. [2013-08-27 10:19:53] contact at jubianchi dot fr I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not "fixed" I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813 [2013-08-27 09:45:12] jpa...@php.net Johannes: I agree, but we could start by patching this bug report right? I got a patch here : https://github.com/jpauli/php- src/compare/class_alias_registration_fix The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1 ID: 61759 Comment by: jpa...@php.net Reported by:ahar...@php.net Summary:class_alias() should accept classes with leading backslashes Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:master-Git-2012-04-18 (Git) Block user comment: N Private report: N New Comment: Yep, let's start finding all places where classes as strings can be used, and patch them all to use zend_lookup_class(). There shouldn't be tons of them AFAIR. Previous Comments: [2013-08-27 10:19:53] contact at jubianchi dot fr I agree with Johannes about consistency. The severity is not really is not very high and this use case can easily be handled at a useland level. As long as this behavior is not "fixed" I think a warning on the doc shoudl be enough, even if I'd like to see it fixed (but as I said, it's not a big deal at the moment). BTW, thanks for you work Julien :) [2013-08-27 10:08:00] johan...@php.net Technically we could, but it adds some inconsistency if one place allows this but others not and that should be avoided. [2013-08-27 09:46:53] jpa...@php.net The following patch has been added/updated: Patch Name: fix-class_alias Revision: 1377596813 URL: https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813 [2013-08-27 09:45:12] jpa...@php.net Johannes: I agree, but we could start by patching this bug report right? I got a patch here : https://github.com/jpauli/php- src/compare/class_alias_registration_fix [2013-08-26 18:32:26] johan...@php.net Note: The bug report is too restrictive. A proper patch would have to work on all places where classnames come from string context. This at first means verifying that all places go via zend_lookup_class() and related functions, not EG(class_table) / CG(class_table) 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=61759 -- Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Bug #65446 [Com]: disk_total_space doesn't work with LVM
Edit report at https://bugs.php.net/bug.php?id=65446&edit=1 ID: 65446 Comment by: r...@php.net Reported by:puciek at gmail dot com Summary:disk_total_space doesn't work with LVM Status: Feedback Type: Bug Package:Filesystem function related Operating System: Centos, Gentoo, Ubuntu PHP Version:5.4.17 Block user comment: N Private report: N New Comment: I means which "exact" value for directory option. If you use "/dev/mapper/batty-root" which is only a file (ok, a special one) it will report about space in /dev (so 4G) If you use "/" it will report about space in / Previous Comments: [2013-08-27 10:29:08] puciek at gmail dot com Director inside LVM share which we want to measure [2013-08-27 09:30:06] r...@php.net I was asking for the option given to the disk_total_space call. [2013-08-27 08:29:57] puciek at gmail dot com df with parameter "-h" changes the output data from bytes to more human readable format -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) [2013-08-27 08:26:32] r...@php.net I cannot reproduce, tested with PHP 5.4.19 / RHEL-6 PHP 5.5.3 / Fedora 19 As this function is a simple wrapper other the statvfs (or statfs), I don't think of a PHP bug. What is the option used in the test call ? [2013-08-13 21:21:13] puciek at gmail dot com Description: Running disk_total_space on a system that is using LVM it will return completely incorrect data. For example on a machine with result of "df -h" as follows: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-vg_root99G 47G 47G 50% / tmpfs 32G 0 32G 0% /dev/shm /dev/sda1194M 65M 120M 36% /boot /dev/mapper/vg-vg_backup 400G 33M 400G 1% /var/tmp /dev/mapper/vg-vg_mysql 950G 81G 870G 9% /data on this setup it will always return 32G. We get similar result on second machine with "df -h": Filesystem Size Used Avail Use% Mounted on /dev/mapper/batty-root 258G 217G 29G 89% / none4.0G 208K 4.0G 1% /dev none4.0G 0 4.0G 0% /dev/shm none4.0G 88K 4.0G 1% /var/run none4.0G 0 4.0G 0% /var/lock none4.0G 0 4.0G 0% /lib/init/rw none258G 217G 29G 89% /var/lib/ureadahead/debugfs where it will always return 4G. At first that it was because of outdated version of PHP, original tests were with PHP version 5.3.27 and 5.3.6, but then I was able to reproduce it on my testing box with Gentoo and PHP 5.4.17. -- Edit this bug report at https://bugs.php.net/bug.php?id=65446&edit=1
Bug #65446 [Com]: disk_total_space doesn't work with LVM
Edit report at https://bugs.php.net/bug.php?id=65446&edit=1 ID: 65446 Comment by: puciek at gmail dot com Reported by:puciek at gmail dot com Summary:disk_total_space doesn't work with LVM Status: Feedback Type: Bug Package:Filesystem function related Operating System: Centos, Gentoo, Ubuntu PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Director inside LVM share which we want to measure Previous Comments: [2013-08-27 09:30:06] r...@php.net I was asking for the option given to the disk_total_space call. [2013-08-27 08:29:57] puciek at gmail dot com df with parameter "-h" changes the output data from bytes to more human readable format -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) [2013-08-27 08:26:32] r...@php.net I cannot reproduce, tested with PHP 5.4.19 / RHEL-6 PHP 5.5.3 / Fedora 19 As this function is a simple wrapper other the statvfs (or statfs), I don't think of a PHP bug. What is the option used in the test call ? [2013-08-13 21:21:13] puciek at gmail dot com Description: Running disk_total_space on a system that is using LVM it will return completely incorrect data. For example on a machine with result of "df -h" as follows: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-vg_root99G 47G 47G 50% / tmpfs 32G 0 32G 0% /dev/shm /dev/sda1194M 65M 120M 36% /boot /dev/mapper/vg-vg_backup 400G 33M 400G 1% /var/tmp /dev/mapper/vg-vg_mysql 950G 81G 870G 9% /data on this setup it will always return 32G. We get similar result on second machine with "df -h": Filesystem Size Used Avail Use% Mounted on /dev/mapper/batty-root 258G 217G 29G 89% / none4.0G 208K 4.0G 1% /dev none4.0G 0 4.0G 0% /dev/shm none4.0G 88K 4.0G 1% /var/run none4.0G 0 4.0G 0% /var/lock none4.0G 0 4.0G 0% /lib/init/rw none258G 217G 29G 89% /var/lib/ureadahead/debugfs where it will always return 4G. At first that it was because of outdated version of PHP, original tests were with PHP version 5.3.27 and 5.3.6, but then I was able to reproduce it on my testing box with Gentoo and PHP 5.4.17. -- Edit this bug report at https://bugs.php.net/bug.php?id=65446&edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1
ID: 61759
Comment by: contact at jubianchi dot fr
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
I agree with Johannes about consistency.
The severity is not really is not very high and this use case can easily be
handled at a useland level.
As long as this behavior is not "fixed" I think a warning on the doc shoudl be
enough, even if I'd like to see it fixed (but as I said, it's not a big deal at
the moment).
BTW, thanks for you work Julien :)
Previous Comments:
[2013-08-27 10:08:00] johan...@php.net
Technically we could, but it adds some inconsistency if one place allows this
but others not and that should be avoided.
[2013-08-27 09:46:53] jpa...@php.net
The following patch has been added/updated:
Patch Name: fix-class_alias
Revision: 1377596813
URL:
https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813
[2013-08-27 09:45:12] jpa...@php.net
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector->getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e->getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
}
Expected result:
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
Or:
bool(true)
string(17) "jubianchi\Alias\A"
bool(false)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
Actual result:
bool(true)
string(1) "A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
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=61759
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Req #61759 [Opn]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1
ID: 61759
Updated by: johan...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
Technically we could, but it adds some inconsistency if one place allows this
but others not and that should be avoided.
Previous Comments:
[2013-08-27 09:46:53] jpa...@php.net
The following patch has been added/updated:
Patch Name: fix-class_alias
Revision: 1377596813
URL:
https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813
[2013-08-27 09:45:12] jpa...@php.net
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector->getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e->getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
}
Expected result:
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
Or:
bool(true)
string(17) "jubianchi\Alias\A"
bool(false)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
Actual result:
bool(true)
string(1) "A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Bug #65499 [Csd]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499&edit=1 ID: 65499 User updated by:m dot kurzyna at crystalpoint dot pl Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON Status: Closed Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: Just to follow up - it has been fixed upstream (both in pecl-json-c and main json-c). Hopefully next distro packages will reflect this changes. Thanks all. Previous Comments: [2013-08-23 07:10:08] m dot kurzyna at crystalpoint dot pl Thanks - I've reported the issue accordingly: https://github.com/remicollet/pecl-json-c/issues/5 [2013-08-23 05:39:05] r...@php.net As Fedora, Ubuntu and some other Linux distributions have switch to JSONC extension, you can report this strictness change in https://github.com/remicollet/pecl-json-c/issues?state=open [2013-08-22 15:16:32] m dot kurzyna at crystalpoint dot pl I'm at Ubuntu. I've built current master (from git) and also didn't reproduce this behaviour so just as you suggest - it seems to be packagers problem. I will report to Ubuntu maintainers. [2013-08-22 11:34:15] yohg...@php.net It seems my fedora 19 x86_64 does this, while my PHP-5.5 branch don't on the same machine. It seems packager's issue. $ php https://bugs.php.net/bug.php?id=65499 -- Edit this bug report at https://bugs.php.net/bug.php?id=65499&edit=1
Req #61759 [PATCH]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1
ID: 61759
Patch added by: jpa...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix-class_alias
Revision: 1377596813
URL:
https://bugs.php.net/patch-display.php?bug=61759&patch=fix-class_alias&revision=1377596813
Previous Comments:
[2013-08-27 09:45:12] jpa...@php.net
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector->getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e->getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
}
Expected result:
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
Or:
bool(true)
string(17) "jubianchi\Alias\A"
bool(false)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
Actual result:
bool(true)
string(1) "A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Req #61759 [Com]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759&edit=1
ID: 61759
Comment by: jpa...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
Previous Comments:
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector->getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e->getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector->getName());
}
Expected result:
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(17) "jubianchi\Alias\A"
Or:
bool(true)
string(17) "jubianchi\Alias\A"
bool(false)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
Actual result:
bool(true)
string(1) "A"
bool(true)
string(17) "jubianchi\Alias\A"
bool(true)
string(60) "ReflectionException: Class \jubianchi\Alias\B does not exist"
bool(true)
string(17) "jubianchi\Alias\A"
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759&edit=1
Bug #65562 [Com]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562&edit=1 ID: 65562 Comment by: ni...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: @johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill. Previous Comments: [2013-08-26 23:15:59] johan...@php.net A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. [2013-08-26 23:02:10] johan...@php.net meant to write "your problem" :-) 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562&edit=1
Bug #65446 [Opn->Fbk]: disk_total_space doesn't work with LVM
Edit report at https://bugs.php.net/bug.php?id=65446&edit=1 ID: 65446 Updated by: r...@php.net Reported by:puciek at gmail dot com Summary:disk_total_space doesn't work with LVM -Status: Open +Status: Feedback Type: Bug Package:Filesystem function related Operating System: Centos, Gentoo, Ubuntu PHP Version:5.4.17 Block user comment: N Private report: N New Comment: I was asking for the option given to the disk_total_space call. Previous Comments: [2013-08-27 08:29:57] puciek at gmail dot com df with parameter "-h" changes the output data from bytes to more human readable format -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) [2013-08-27 08:26:32] r...@php.net I cannot reproduce, tested with PHP 5.4.19 / RHEL-6 PHP 5.5.3 / Fedora 19 As this function is a simple wrapper other the statvfs (or statfs), I don't think of a PHP bug. What is the option used in the test call ? [2013-08-13 21:21:13] puciek at gmail dot com Description: Running disk_total_space on a system that is using LVM it will return completely incorrect data. For example on a machine with result of "df -h" as follows: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-vg_root99G 47G 47G 50% / tmpfs 32G 0 32G 0% /dev/shm /dev/sda1194M 65M 120M 36% /boot /dev/mapper/vg-vg_backup 400G 33M 400G 1% /var/tmp /dev/mapper/vg-vg_mysql 950G 81G 870G 9% /data on this setup it will always return 32G. We get similar result on second machine with "df -h": Filesystem Size Used Avail Use% Mounted on /dev/mapper/batty-root 258G 217G 29G 89% / none4.0G 208K 4.0G 1% /dev none4.0G 0 4.0G 0% /dev/shm none4.0G 88K 4.0G 1% /var/run none4.0G 0 4.0G 0% /var/lock none4.0G 0 4.0G 0% /lib/init/rw none258G 217G 29G 89% /var/lib/ureadahead/debugfs where it will always return 4G. At first that it was because of outdated version of PHP, original tests were with PHP version 5.3.27 and 5.3.6, but then I was able to reproduce it on my testing box with Gentoo and PHP 5.4.17. -- Edit this bug report at https://bugs.php.net/bug.php?id=65446&edit=1
Bug #65446 [Com]: disk_total_space doesn't work with LVM
Edit report at https://bugs.php.net/bug.php?id=65446&edit=1 ID: 65446 Comment by: puciek at gmail dot com Reported by:puciek at gmail dot com Summary:disk_total_space doesn't work with LVM Status: Open Type: Bug Package:Filesystem function related Operating System: Centos, Gentoo, Ubuntu PHP Version:5.4.17 Block user comment: N Private report: N New Comment: df with parameter "-h" changes the output data from bytes to more human readable format -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) Previous Comments: [2013-08-27 08:26:32] r...@php.net I cannot reproduce, tested with PHP 5.4.19 / RHEL-6 PHP 5.5.3 / Fedora 19 As this function is a simple wrapper other the statvfs (or statfs), I don't think of a PHP bug. What is the option used in the test call ? [2013-08-13 21:21:13] puciek at gmail dot com Description: Running disk_total_space on a system that is using LVM it will return completely incorrect data. For example on a machine with result of "df -h" as follows: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-vg_root99G 47G 47G 50% / tmpfs 32G 0 32G 0% /dev/shm /dev/sda1194M 65M 120M 36% /boot /dev/mapper/vg-vg_backup 400G 33M 400G 1% /var/tmp /dev/mapper/vg-vg_mysql 950G 81G 870G 9% /data on this setup it will always return 32G. We get similar result on second machine with "df -h": Filesystem Size Used Avail Use% Mounted on /dev/mapper/batty-root 258G 217G 29G 89% / none4.0G 208K 4.0G 1% /dev none4.0G 0 4.0G 0% /dev/shm none4.0G 88K 4.0G 1% /var/run none4.0G 0 4.0G 0% /var/lock none4.0G 0 4.0G 0% /lib/init/rw none258G 217G 29G 89% /var/lib/ureadahead/debugfs where it will always return 4G. At first that it was because of outdated version of PHP, original tests were with PHP version 5.3.27 and 5.3.6, but then I was able to reproduce it on my testing box with Gentoo and PHP 5.4.17. -- Edit this bug report at https://bugs.php.net/bug.php?id=65446&edit=1
Bug #65446 [Opn]: disk_total_space doesn't work with LVM
Edit report at https://bugs.php.net/bug.php?id=65446&edit=1 ID: 65446 Updated by: r...@php.net Reported by:puciek at gmail dot com Summary:disk_total_space doesn't work with LVM Status: Open Type: Bug Package:Filesystem function related Operating System: Centos, Gentoo, Ubuntu PHP Version:5.4.17 Block user comment: N Private report: N New Comment: I cannot reproduce, tested with PHP 5.4.19 / RHEL-6 PHP 5.5.3 / Fedora 19 As this function is a simple wrapper other the statvfs (or statfs), I don't think of a PHP bug. What is the option used in the test call ? Previous Comments: [2013-08-13 21:21:13] puciek at gmail dot com Description: Running disk_total_space on a system that is using LVM it will return completely incorrect data. For example on a machine with result of "df -h" as follows: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-vg_root99G 47G 47G 50% / tmpfs 32G 0 32G 0% /dev/shm /dev/sda1194M 65M 120M 36% /boot /dev/mapper/vg-vg_backup 400G 33M 400G 1% /var/tmp /dev/mapper/vg-vg_mysql 950G 81G 870G 9% /data on this setup it will always return 32G. We get similar result on second machine with "df -h": Filesystem Size Used Avail Use% Mounted on /dev/mapper/batty-root 258G 217G 29G 89% / none4.0G 208K 4.0G 1% /dev none4.0G 0 4.0G 0% /dev/shm none4.0G 88K 4.0G 1% /var/run none4.0G 0 4.0G 0% /var/lock none4.0G 0 4.0G 0% /lib/init/rw none258G 217G 29G 89% /var/lib/ureadahead/debugfs where it will always return 4G. At first that it was because of outdated version of PHP, original tests were with PHP version 5.3.27 and 5.3.6, but then I was able to reproduce it on my testing box with Gentoo and PHP 5.4.17. -- Edit this bug report at https://bugs.php.net/bug.php?id=65446&edit=1
