Bug #65419 [Ver]: Inside trait, self::class != __CLASS__
Edit report at https://bugs.php.net/bug.php?id=65419&edit=1 ID: 65419 Updated by: ralphschind...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:Inside trait, self::class != __CLASS__ Status: Verified Type: Bug Package:Scripting Engine problem PHP Version:5.5.1 -Assigned To: +Assigned To:ralphschindler Block user comment: N Private report: N New Comment: Ill work up a patch that will demonstrate ::class resolving in traits similar to how __CLASS__ works in traits. This seems to be the consensus (correct me if I am wrong), and consistent with __CLASS__ (to some degree) in traits. Previous Comments: [2013-08-14 10:10:48] nicolas dot grekas+php at gmail dot com Why remove ::class support inside traits? It mostly works today, and it is as usefull there than inside classes or anywhere else, am I wrong? Would it be possible to replace self::class occurences by __CLASS__ at compile time so that the code path for __CLASS__ is also used here? [2013-08-11 15:31:06] larue...@php.net I prefer to trigger a COMPILE ERROR prevent from using ::class in a traits [2013-08-09 07:57:41] g...@php.net Yes, that looks wrong. It should indeed behave as __CLASS__. [2013-08-09 07:55:23] nicolas dot grekas+php at gmail dot com I totally agree with you. This reminds me the discussion that happened in https://bugs.php.net/55214 and that led to this special handling for __CLASS__. I think that the very same arguments apply here also. Concerning parent and static, they are free from this problem because they are resolved at run-time (tested, it works). [2013-08-08 18:33:55] requi...@php.net The RFC was created a few weeks after 5.4.0 was released and does not specify how self::class would work for traits. I would take that to mean the writer did not consider how it would work for traits, rather than that traits should "inherit" the behavior for classes. So either this is a doc bug and the ::class doc should state that it resolves to the trait itself when used for traits (as a "::trait" syntax would be weird), or self::class is fixed so be identical to __CLASS__. Presumably parent::class and static::class would receive similar changes. Note for the latter: in zend_language_scanner, __CLASS__ has special handling when used inside traits. I imagine similar logic - creating "a special __CLASS__ constant" - would be used in zend_do_resolve_class_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=65419 -- Edit this bug report at https://bugs.php.net/bug.php?id=65419&edit=1
Bug #50797 [Asn->Csd]: PHAR fails to extract ZIP archives, but TAR is ok
Edit report at https://bugs.php.net/bug.php?id=50797&edit=1
ID: 50797
Updated by: ralphschind...@php.net
Reported by:legolas558 at users dot sourceforge dot net
Summary:PHAR fails to extract ZIP archives, but TAR is ok
-Status: Assigned
+Status: Closed
Type: Bug
Package:PHAR related
Operating System: Linux 2.6.33-rc4
PHP Version:5.3.1
-Assigned To:cellog
+Assigned To:ralphschindler
Block user comment: N
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
[2012-07-03 16:02:50] ralphschind...@php.net
Is this still an issue, if so, do you have a phar zip that I can use to
reproduce
this problem? Or will any zip do?
[2011-10-30 09:01:29] mep_eisen at web dot de
Seemed to fall over the same issue. However using file_get_contents and
manually extract them will return the correct content. But extractTo does not.
Using windows 7 and php 5.3.3.
[2010-01-19 07:28:28] legolas558 at users dot sourceforge dot net
My Arch linux system is using zlib 1.2.3.4-3 and no other issues with ZIP files
[2010-01-19 07:23:59] legolas558 at users dot sourceforge dot net
Description:
PHAR extraction of Zip archives is broken
Reproduce code:
---
extractTo('/tmp', null, true); // extract all files, and overwrite
} catch (Exception $e) {
echo $e;
// handle errors
}
?>
Expected result:
When running phartest.php with a zip file, it extracts files with no failure
but files contain garbage. File size corresponds but content does not. The
script works with TAR or TAR.GZ files seamlessly, so I suspect it's due to some
library bug. Files in ZIP archive are compressed with normal Deflate method.
Actual result:
--
Hexdump of "phartest.php" extracted from a "phartest.zip" archive containing
only the phartest.php script.
000 8e45 0abd 30c2 8514 f367 6714 b428 4a85
010 ae71 8bb6 0eee e26e e210 14d5 1362 6f6e
020 447f eefa 1146 d33c be19 b3f3 826d 4a0d
030 89f8 4297 1254 66ac d0ec 84d1 b463 2d7b
040 4b3a df34 f3c7 92e6 7f57 5d66 2cd3 8dac
050 7c9c 9696 08f2 8169 706e 80ae 40f0 8579
060 c4b2 808f 0e76 d6b7 5f51 7740 f857 7891
070 56e2 2d48 5a30 458c 9876 050d 7d69 8487
080 78f2 4565 fac6 bfe8 9f83 1b2a 8e83 cc40
090 7b9e a8b5 56a6 0dea 4b50 0201 0314 0314
0a0 0008 4145 3c33 830d bec4 0098
0b0 00bc 000c
0bc
--
Edit this bug report at https://bugs.php.net/bug.php?id=50797&edit=1
Bug #64343 [Opn]: PharData::extractTo fails for tarball created by BSD tar
Edit report at https://bugs.php.net/bug.php?id=64343&edit=1
ID: 64343
Updated by: ralphschind...@php.net
Reported by:njh at aelius dot com
Summary:PharData::extractTo fails for tarball created by BSD
tar
Status: Open
Type: Bug
Package:PHAR related
Operating System: Mac OS 10.7.5
PHP Version:5.4.12
-Assigned To:
+Assigned To:ralphschindler
Block user comment: N
Private report: N
New Comment:
How did you create these tar files? On mac (10.8.2), I did:
tar cvf my-bsd.tar test.txt
This created a ustar format tar file. Yours seems to be a pax format tar file,
which I can't see how that is the default format on mac?
Previous Comments:
[2013-03-03 19:52:02] njh at aelius dot com
Description:
The extractTo() method in Phar doesn't seem to work with tar archives generated
using the BSD version of the tar tool, which is the version that comes pre-
installed on Mac OS X.
I have uploaded two sample tar files, which both contain a single test.txt file:
http://www.aelius.com/njh/tmp/tartest/test-bsd.tar.gz
http://www.aelius.com/njh/tmp/tartest/test-gnu.tar.gz
When run the GNU generated tar file works correctly but the BSD generated tar
file fails.
This problem came up with trying to install dependencies using composer, that
had been generated using BSD tar on Mac OS X:
https://github.com/composer/composer/issues/1492
Test script:
---
extractTo('extracted-gnu');
$phar = new PharData('test-bsd.tar.gz');
$phar->extractTo('extracted-bsd');
Expected result:
Both the test-bsd.tar.gz and test-gnu.tar.gz should extract the test.txt file.
Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message 'phar
error: "/tmp/tartest/test-bsd.tar.gz" is a corrupted tar file (checksum
mismatch
of file "18 uid=1451698731
20 ctime=1362335175
20 atime=1362335267
24 SCHILY.dev=234881029
23 SCHILY.ino=1224")' in /tmp/tartest/test.php:5
Stack trace:
#0 /tmp/tartest/test.php(5): PharData->__construct('test-bsd.tar.gz')
#1 {main}
thrown in /tmp/tartest/test.php on line 5
--
Edit this bug report at https://bugs.php.net/bug.php?id=64343&edit=1
Bug #60890 [Opn->Nab]: Can not read tgz file through Phar class, but related path works
Edit report at https://bugs.php.net/bug.php?id=60890&edit=1 ID: 60890 Updated by: ralphschind...@php.net Reported by:cornelius dot howl at gmail dot com Summary:Can not read tgz file through Phar class, but related path works -Status: Open +Status: Not a bug Type: Bug Package:PHAR related Operating System: Mac OS 10.6 PHP Version:5.3.9 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 filename passed to the first parameter of the Phar constructor must contain .phar in the file's extension to be created/opened. Previous Comments: [2012-01-26 12:04:29] cornelius dot howl at gmail dot com Description: Can not read tgz file with realpath, offsetGet works, offsetSet doesnt work. $p['file'] = 'content'; will fail. See: https://gist.github.com/1682446 Test script: --- https://gist.github.com/1682446 Actual result: -- See: https://gist.github.com/1682446 -- Edit this bug report at https://bugs.php.net/bug.php?id=60890&edit=1
Req #64871 [Asn->Wfx]: The ::class operator should verify the class name
Edit report at https://bugs.php.net/bug.php?id=64871&edit=1 ID: 64871 Updated by: ralphschind...@php.net Reported by:vr...@php.net Summary:The ::class operator should verify the class name -Status: Assigned +Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:5.5.0RC1 Assigned To:ralphschindler Block user comment: N Private report: N New Comment: I believe this came up, and I wouldn't support this. This would be inconsistent with the current implementation of namespaces. use Foo\Bar\Baz; for example, does not check the existence of Baz on "use". It is not not till a type is used (either statically called or used to create a new instance of via new) that it will trigger autoloading (if there is one). There are many places in PHP where type names are used, method signatures, and even in the following example: $x = new stdClass; var_dump($x instanceof FooBar); PHP will not attempt to autoload FooBar to for the purposes of instanceof. If you need to know that a particular type exists, class_exists(foo::class, true); should do what you need. If you feel differently, I think you should bring this up on the internals mailing list. Previous Comments: [2013-05-17 16:49:21] vr...@php.net Ralph, what's your take on this? [2013-05-17 16:48:42] vr...@php.net Description: One of the main advantages of the ::class operator could be that it verifies the class name upon creating the string instead of upon usage. It should trigger autoloading if the class doesn't exist. I know that it's somewhat late to change this in PHP 5.5 but I was really surprised by the lack of this feature and about the fact that it wasn't considered in RFC. Test script: --- https://bugs.php.net/bug.php?id=64871&edit=1
Req #64871 [Wfx]: The ::class operator should verify the class name
Edit report at https://bugs.php.net/bug.php?id=64871&edit=1 ID: 64871 Updated by: ralphschind...@php.net Reported by:vr...@php.net Summary:The ::class operator should verify the class name Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:5.5.0RC1 Assigned To:ralphschindler Block user comment: N Private report: N New Comment: David, I am not sure what behavior you're referencing. When does callable trigger autoload? Perhaps this is a conversation for the internals mailing list? Previous Comments: [2013-05-17 18:34:04] David at grudl dot com Ralph, totally agree. What do you think about fixing type hint "callable" to not trigger autoloading? [2013-05-17 18:23:40] vr...@php.net Makes sense, thanks for the explanation. [2013-05-17 17:16:08] ralphschind...@php.net I believe this came up, and I wouldn't support this. This would be inconsistent with the current implementation of namespaces. use Foo\Bar\Baz; for example, does not check the existence of Baz on "use". It is not not till a type is used (either statically called or used to create a new instance of via new) that it will trigger autoloading (if there is one). There are many places in PHP where type names are used, method signatures, and even in the following example: $x = new stdClass; var_dump($x instanceof FooBar); PHP will not attempt to autoload FooBar to for the purposes of instanceof. If you need to know that a particular type exists, class_exists(foo::class, true); should do what you need. If you feel differently, I think you should bring this up on the internals mailing list. [2013-05-17 16:49:21] vr...@php.net Ralph, what's your take on this? [2013-05-17 16:48:42] vr...@php.net Description: One of the main advantages of the ::class operator could be that it verifies the class name upon creating the string instead of upon usage. It should trigger autoloading if the class doesn't exist. I know that it's somewhat late to change this in PHP 5.5 but I was really surprised by the lack of this feature and about the fact that it wasn't considered in RFC. Test script: --- https://bugs.php.net/bug.php?id=64871&edit=1
Bug #55195 [Com]: PharData::buildFromDirectory does not seem to close the file after archiving
Edit report at https://bugs.php.net/bug.php?id=55195&edit=1
ID: 55195
Comment by: ralph at ralphschindler dot com
Reported by:kedomingo at gmail dot com
Summary:PharData::buildFromDirectory does not seem to close
the file after archiving
Status: Open
Type: Bug
Package:PHAR related
Operating System: Windows 7 Professional 32bit
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Why should you be able to delete the currently open phar?
It seems to me that $file2 is still open for modification in PHP, for example,
you can call setStub(), or add new files or metadata to the $phar you have
open.
Since this is the case,
Even unlinkArchive() seems to imply in its documentation that the $phar needs
to
have the reference removed before you can unlink it:
http://www.php.net/manual/en/phar.unlinkarchive.php
I am inclined to say that this is not an issue.
Previous Comments:
[2012-04-21 20:23:19] michaelmotes at email dot com
I worked around this bug by simply destroying the phar object, unset($phar).
[2011-07-12 22:37:59] kedomingo at gmail dot com
Description:
While I can create a file, write to it, close it, and delete it via unlink, I
can't delete a file created by the buildFromDirectory function of PharData. I
suspect that the file has been left open.
Test script:
---
\n";
if( !fwrite($f, 'test') ) echo "Could not write to $file \n";
if( !fclose($f) ) echo "Could not close $file \n";
if( !unlink($file) )echo "Could not delete $file \n";
if( !is_dir( $dir = dirname(__FILE__) . '/phartest' ) ) { /// Create test
directory for PharData
mkdir( dirname(__FILE__) . '/phartest' );
for($i = 0; $i < 3; $i++) { $f = fopen($dir . "/file$i.txt", 'w');
fwrite($f, $i); fclose($f); };
}
$file2 = uniqid().".zip"; /// Create test archive in the same directory as the
demo file
$phar = new PharData($file2);
if( $phar->buildFromDirectory($dir) )
if(!unlink($file2)) /// Did phar close the file? Can we delete it?
echo "Could not delete $file2!";
?>
Expected result:
I expect that the call to unlink($file2) will delete the newly created archive
(with filename $file2)
Actual result:
--
Warning: unlink(<$file2>): Permission denied in C:\htdocs\phartest.php on line
17
Could not delete <$file2>!
--
Edit this bug report at https://bugs.php.net/bug.php?id=55195&edit=1
Bug #52406 [Com]: spl_autoload support phar with namespace
Edit report at https://bugs.php.net/bug.php?id=52406&edit=1
ID: 52406
Comment by: ralph at ralphschindler dot com
Reported by:jinmoku at hotmail dot com
Summary:spl_autoload support phar with namespace
Status: Open
Type: Bug
Package:PHAR related
Operating System: XP, OSX
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
This is not an issue, spl_autoload() is working as described, and furthermore,
this is not a PHAR issue.
Can someone close?
-ralph
Previous Comments:
[2011-02-10 21:50:16] jinmoku at hotmail dot com
it's more a PHAR problem
[2011-02-10 21:49:24] jinmoku at hotmail dot com
Add detect_unicode to off for OSX :
ini_set('detect_unicode', false);
I think all the files should be automatically put in lowercase.
[2011-02-09 10:37:10] jinmoku at hotmail dot com
Only way to work :
$phar->addFromString(strtolower('index.php'), $index);
$phar->addFromString(strtolower('Framework/Test.php'), $contents);
or maybe do it in internal
[2010-07-23 11:11:51] jinmoku at hotmail dot com
Ok, I retry on XP and it's work, even if it isn't simple, a filename in project
is not always in lowercase...
Unfortunately it's doesn't work on osx, we see : set_include_path('phar://' .
__FILE__ . PATH_SEPARATOR . get_include_path());
but after the require_once the phar path's gone, i'll check on other system and
I come back
;)
[2010-07-23 01:59:42] fel...@php.net
What I am saying is:
- Using require_once you might use (lowercase not required):
$phar->addFromString('Framework/Test.php', $contents);
require_once 'Framework/Test.php'; // the search is non-lowercased
- Using spl_autoload() you must use (lowercase required):
$phar->addFromString('framework/test.php', $contents);
$test = new Framework\Test(); // spl_autoload() searchs for the lowercased
namespace/classname.php
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=52406
--
Edit this bug report at https://bugs.php.net/bug.php?id=52406&edit=1
[PHP-BUG] Bug #60164 [NEW]: Stubs of a specific length break phar_open_from_fp scanning for __HALT_COMPILER
From: Operating system: All PHP version: 5.3SVN-2011-10-28 (snap) Package: PHAR related Bug Type: Bug Bug description:Stubs of a specific length break phar_open_from_fp scanning for __HALT_COMPILER Description: Stubs who's content before the __HALT_COMPILER(); registers between 1007 - 1023 bytes (or an interval thereof) will force the function phar_open_from_fp() to incorrectly throw an MAPPHAR_ALLOC_FAIL() or: Fatal error: Uncaught exception 'UnexpectedValueException' with message 'internal corruption of phar "xxx/test.phar" (__HALT_COMPILER(); not found)' in xxx/test.php:5 This is due to an incorrect index in the memmove() call inside the function that shifts the buffer to inspect the contents for the __HALT_COMPILER() token. THis bug is exposed when opening a phar and iterating the contents. Attached is a sample phar, test script, and patch Test script: --- Expected result: Iterate the results. Actual result: -- Fatal error: Uncaught exception 'UnexpectedValueException' with message 'internal corruption of phar "xxx/test.phar" (__HALT_COMPILER(); not found)' in xxx/test.php:5 -- Edit bug report at https://bugs.php.net/bug.php?id=60164&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60164&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60164&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60164&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60164&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60164&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60164&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60164&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60164&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60164&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60164&r=support Expected behavior: https://bugs.php.net/fix.php?id=60164&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60164&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60164&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60164&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60164&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60164&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60164&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60164&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60164&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60164&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60164&r=mysqlcfg
Bug #60164 [Com]: Stubs of a specific length break phar_open_from_fp scanning for __HALT_COMPILER
Edit report at https://bugs.php.net/bug.php?id=60164&edit=1 ID: 60164 Comment by: ralph at ralphschindler dot com Reported by:ralph at ralphschindler dot com Summary:Stubs of a specific length break phar_open_from_fp scanning for __HALT_COMPILER Status: Open Type: Bug Package:PHAR related Operating System: All PHP Version:5.3SVN-2011-10-28 (snap) Block user comment: N Private report: N New Comment: This is the fix for the issue: https://github.com/ralphschindler/php- src/commit/5bf57e28b7090aaf0428a984b90a11d25c12b22e I will prepare a patch for trunk/5_3/5_4 along with tests. Previous Comments: [2011-10-28 19:46:37] ralph at ralphschindler dot com Description: Stubs who's content before the __HALT_COMPILER(); registers between 1007 - 1023 bytes (or an interval thereof) will force the function phar_open_from_fp() to incorrectly throw an MAPPHAR_ALLOC_FAIL() or: Fatal error: Uncaught exception 'UnexpectedValueException' with message 'internal corruption of phar "xxx/test.phar" (__HALT_COMPILER(); not found)' in xxx/test.php:5 This is due to an incorrect index in the memmove() call inside the function that shifts the buffer to inspect the contents for the __HALT_COMPILER() token. THis bug is exposed when opening a phar and iterating the contents. Attached is a sample phar, test script, and patch Test script: --- Expected result: Iterate the results. Actual result: -- Fatal error: Uncaught exception 'UnexpectedValueException' with message 'internal corruption of phar "xxx/test.phar" (__HALT_COMPILER(); not found)' in xxx/test.php:5 -- Edit this bug report at https://bugs.php.net/bug.php?id=60164&edit=1
