[PHP-BUG] Bug #53865 [NEW]: (float)0 * -1 = minus zero (-0)
From: Operating system: Windows 7 PHP version: 5.3.5 Package: Scripting Engine problem Bug Type: Bug Bug description:(float)0 * -1 = minus zero (-0) Description: See test script. Test script: --- var_dump( (float)0 * -1); Expected result: float(0) Actual result: -- float(-0) -- Edit bug report at http://bugs.php.net/bug.php?id=53865edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53865r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53865r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53865r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53865r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53865r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53865r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53865r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53865r=needscript Try newer version: http://bugs.php.net/fix.php?id=53865r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53865r=support Expected behavior: http://bugs.php.net/fix.php?id=53865r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53865r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53865r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53865r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53865r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53865r=dst IIS Stability: http://bugs.php.net/fix.php?id=53865r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53865r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53865r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53865r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53865r=mysqlcfg
Bug #53803 [Opn]: circular reference between SPL classes not collected by gc_collect_cycles()
Edit report at http://bugs.php.net/bug.php?id=53803edit=1
ID: 53803
User updated by:oliver at openbrackets dot net
Reported by:oliver at openbrackets dot net
Summary:circular reference between SPL classes not collected
by gc_collect_cycles()
Status: Open
Type: Bug
Package:SPL related
Operating System: FreeBSD
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
ok, that makes sense.
By saying:
I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
Are you suggesting that it would be possible to rewrite the test Case1
using SplObjectStorage? Or that we have to live with GC not being able
to clean up these circular references for th time being?
Previous Comments:
[2011-01-27 16:12:04] cataphr...@php.net
The fix for bug #53071 never claimed to fix all circular reference
problems in SPL classes, it fixed only the behavior in
SPLObjectStorage.
In fact, the problem is a design one and it is caused by the inability
of the garbage collector to know an object holds a reference to a
certain variable except through a property contained in the hash table
returned by the get_properties handler.
The fix to bug #53071 is actually a quite a hack; a proper solution
would involve maybe adding an extra object handler for the garbage
collector to use, but that cannot be done in the 5.3 branch. I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic.
[2011-01-21 13:09:57] oliver at openbrackets dot net
Description:
Circular references between instances of SPL classes are not cleaned
up by gc_collect_cycles().
The code in the test script can be run from cli. It shows growing memory
usage because the circular references between the instances of an
extended ArrayObject class and instances of ArrayIterator are not
cleaned up by gc_collect_cycles.
The long code sample, downloadable from the url provided in test script
section shows:
Case1: SPL classes: expecting gc_collect_cycles to clean up circ
references
Case2: SPL classes: manual clearing of the circular reference
Case3: Userland classes: expecting gc_collect_cycles to clean up circ
references
This looks similar to http://bugs.php.net/53071 , BUT I am running
php5.3.5 which AFAIK includes r304723 and r304724 which were supposed to
fix #53071.
Test script:
---
Short code sample:
class Collection extends ArrayObject implements Serializable
{
protected $iterator;
public function getIterator()
{
$this-iterator = new ArrayIterator($this);
return $this-iterator;
}
public function clearIterator()
{
$this-iterator = null;
}
}
echo Case 1: ArrayObject/ArrayIterator: expecting gc_collect_cycles()
to clean up...\n;
for ($i = 1; $i = 100; $i++)
{
$books = array('war and peace', 'crime and punishment');
$book_collection = new Collection($books);
$iterator = $book_collection-getIterator();
echo gc_collect_cycles() . : . memory_get_peak_usage() . \n;
}
full code sample:
http://www.realtsp.com/download/php_circular_reference_test_code_sample.txt
Expected result:
Expect all test cases (Case1, Case2, Case3) to have constant peak memory
usage.
Actual result:
--
Only Case2 and Case3 have constant memory usage.
In Case1 memory usage grows linearly with loops iterations.
This shows that gc_collect_cycles is not collecting circular references
between SPL classes. Also shown because it returns 0 cycles collected.
In Case 3 (Userland classes) gc_collect_cycles shows 5 cycles
collected each iteration.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53803edit=1
Bug #53858 [Opn]: infinite loop in __tostring() causes seg fault
Edit report at http://bugs.php.net/bug.php?id=53858edit=1
ID: 53858
Updated by: scott...@php.net
Reported by:alok at fb dot com
Summary:infinite loop in __tostring() causes seg fault
Status: Open
Type: Bug
Package:Class/Object related
Operating System: All
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
This is a crash in stock PHP 5.2 too, Our version in APE has a patch
that adds
fb.recursion_max and overrides zend_execute to do the counting.
Previous Comments:
[2011-01-27 19:01:25] alok at fb dot com
Description:
The following piece of code would cause PHP Fatal error: [php_fb]:
call depth has exceeded the maximum recursion setting of 500!, eject!
eject! eject!... in 5.2.5. However, on versions 5.3.3 and 5.3.5, I am
seeing a segmentation fault.
Test script:
---
?php
class A { public function __toString() { (string)$this; } }
(string)new A();
Expected result:
PHP Fatal error: [php_fb]: call depth has exceeded the maximum
recursion setting of 500!, eject! eject! eject!... seems a reasonable
result.
Actual result:
--
segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=53858edit=1
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1 ID: 53854 Updated by: rquadl...@php.net Reported by:rquadl...@php.net Summary:Missing constants for compression type. Status: Assigned Type: Bug Package:Zip Related Operating System: n/a PHP Version:5.3SVN-2011-01-27 (SVN) Assigned To:aharvey Block user comment: N Private report: N New Comment: As the compression mechanisms are stored within the zip file itself, it isn't necessarily a requirement for php_zip to support compression/decompression of these types, just identification. Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA, CM_BZIP and CM_WAVPACK compressions. Still looking for LZ77 and Terse. The compression types are correctly identified by php_zip, so having the constants makes sense to me. I'll update the documentation to say that whilst identification of these types is performed, compression and decompression of these types is not currently supported. Previous Comments: [2011-01-28 07:43:12] paj...@php.net Are you sure all compression modes are implemented? I don't think they are, afair that's also why I did not add them. [2011-01-28 05:19:55] ahar...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-01-28 05:19:43] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307807 Log: Fixed bug #53854 (Missing constants for compression type). Patch by Richard Quadling. [2011-01-27 14:55:29] rquadl...@php.net The following patch has been added/updated: Patch Name: missing_zip_constants.patch Revision: 1296136529 URL: http://bugs.php.net/patch-display.php?bug=53854patch=missing_zip_constants.patchrevision=1296136529 [2011-01-27 14:54:59] rquadl...@php.net Description: ext/zip internally uses several constants to identify the nature of the compressed content. Not all of these are exposed, though one of them is documented (ZipArchive::CM_BZIP2). The attached patch for ext/zip/php_zip.c adds the missing constants. Once this is committed, I can update the documentation with the others (LZMA, TERSE, LZ77, WAVPACK and PPMD). -- Edit this bug report at http://bugs.php.net/bug.php?id=53854edit=1
Bug #53865 [Opn-Bgs]: (float)0 * -1 = minus zero (-0)
Edit report at http://bugs.php.net/bug.php?id=53865edit=1 ID: 53865 Updated by: der...@php.net Reported by:dmitrij at stepanov dot lv Summary:(float)0 * -1 = minus zero (-0) -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . Previous Comments: [2011-01-28 10:03:40] dmitrij at stepanov dot lv Description: See test script. Test script: --- var_dump( (float)0 * -1); Expected result: float(0) Actual result: -- float(-0) -- Edit this bug report at http://bugs.php.net/bug.php?id=53865edit=1
Bug #53865 [Com]: (float)0 * -1 = minus zero (-0)
Edit report at http://bugs.php.net/bug.php?id=53865edit=1 ID: 53865 Comment by: dmitrij at stepanov dot lv Reported by:dmitrij at stepanov dot lv Summary:(float)0 * -1 = minus zero (-0) Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I guess the link should be http://en.wikipedia.org/wiki/IEEE_754 Previous Comments: [2011-01-28 11:23:02] der...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . [2011-01-28 10:03:40] dmitrij at stepanov dot lv Description: See test script. Test script: --- var_dump( (float)0 * -1); Expected result: float(0) Actual result: -- float(-0) -- Edit this bug report at http://bugs.php.net/bug.php?id=53865edit=1
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1 ID: 53854 Updated by: paj...@php.net Reported by:rquadl...@php.net Summary:Missing constants for compression type. Status: Assigned Type: Bug Package:Zip Related Operating System: n/a PHP Version:5.3SVN-2011-01-27 (SVN) Assigned To:aharvey Block user comment: N Private report: N New Comment: If they are not implemented, no, it does not make sense to have them exposed. If one uses them he will then expect the compression mode to be set and used accordingly. However for reading archive and get information about a given compression mode, yes. But only if they are actually used and set by libzip. If not, please revert this change. Previous Comments: [2011-01-28 11:22:37] rquadl...@php.net As the compression mechanisms are stored within the zip file itself, it isn't necessarily a requirement for php_zip to support compression/decompression of these types, just identification. Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA, CM_BZIP and CM_WAVPACK compressions. Still looking for LZ77 and Terse. The compression types are correctly identified by php_zip, so having the constants makes sense to me. I'll update the documentation to say that whilst identification of these types is performed, compression and decompression of these types is not currently supported. [2011-01-28 07:43:12] paj...@php.net Are you sure all compression modes are implemented? I don't think they are, afair that's also why I did not add them. [2011-01-28 05:19:55] ahar...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-01-28 05:19:43] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307807 Log: Fixed bug #53854 (Missing constants for compression type). Patch by Richard Quadling. [2011-01-27 14:55:29] rquadl...@php.net The following patch has been added/updated: Patch Name: missing_zip_constants.patch Revision: 1296136529 URL: http://bugs.php.net/patch-display.php?bug=53854patch=missing_zip_constants.patchrevision=1296136529 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53854 -- Edit this bug report at http://bugs.php.net/bug.php?id=53854edit=1
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1
ID: 53854
Updated by: rquadl...@php.net
Reported by:rquadl...@php.net
Summary:Missing constants for compression type.
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: n/a
PHP Version:5.3SVN-2011-01-27 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
I took a file (an uncompressed WAV file) and compressed it using WinZip
V15 using different algorithms.
Using the following code ...
?php
$zip = new ZipArchive;
$zip-open('wav.zipx');
foreach(range(0, $zip-numFiles - 1) as $index) {
print_r($stat = $zip-statIndex($index));
$zip-extractTo('.', array($stat['name']));
echo $zip-getStatusString(), PHP_EOL;
}
$zip-close();
Outputs ...
Array
(
[name] = WavPack.wav
[index] = 0
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 45366
[comp_method] = 97
)
Compression method not supported
Array
(
[name] = PPMD.wav
[index] = 1
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 100729
[comp_method] = 98
)
Compression method not supported
Array
(
[name] = LZMA.wav
[index] = 2
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 68162
[comp_method] = 14
)
Compression method not supported
Array
(
[name] = BZIP2.wav
[index] = 3
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 104633
[comp_method] = 12
)
Compression method not supported
As you can see, 98, 97, 14 and 12 are all identified as the comp_method
(correctly). None of these compression methods are supported by php_zip,
but the constants should be present to allow determination of the method
used.
Interestingly WavPack was the best algorithm to use on uncompressed
audio (which WinZip performed when I asked it to compress to the
smallest size).
I can send the zip file if needed (300K).
I think it is important to remember that the zip files being accessed by
php_zip may not have been produced by php_zip.
Previous Comments:
[2011-01-28 11:34:43] paj...@php.net
If they are not implemented, no, it does not make sense to have them
exposed. If
one uses them he will then expect the compression mode to be set and
used
accordingly.
However for reading archive and get information about a given
compression mode,
yes. But only if they are actually used and set by libzip. If not,
please revert
this change.
[2011-01-28 11:22:37] rquadl...@php.net
As the compression mechanisms are stored within the zip file itself, it
isn't
necessarily a requirement for php_zip to support
compression/decompression of these
types, just identification.
Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA,
CM_BZIP and
CM_WAVPACK compressions.
Still looking for LZ77 and Terse.
The compression types are correctly identified by php_zip, so having the
constants
makes sense to me.
I'll update the documentation to say that whilst identification of these
types is
performed, compression and decompression of these types is not currently
supported.
[2011-01-28 07:43:12] paj...@php.net
Are you sure all compression modes are implemented? I don't think they
are, afair
that's also why I did not add them.
[2011-01-28 05:19:55] ahar...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2011-01-28 05:19:43] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307807
Log: Fixed bug #53854 (Missing constants for compression type). Patch by
Richard
Quadling.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53854
--
Edit this bug report at http://bugs.php.net/bug.php?id=53854edit=1
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1
ID: 53854
Updated by: paj...@php.net
Reported by:rquadl...@php.net
Summary:Missing constants for compression type.
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: n/a
PHP Version:5.3SVN-2011-01-27 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
That's what I asked. We can keep them only and only if libzip detects
AND uses
these compression types correctly. It seems to be the case. Can you
confirm it and
maybe add a test per compression method?
Previous Comments:
[2011-01-28 12:03:35] rquadl...@php.net
I took a file (an uncompressed WAV file) and compressed it using WinZip
V15 using different algorithms.
Using the following code ...
?php
$zip = new ZipArchive;
$zip-open('wav.zipx');
foreach(range(0, $zip-numFiles - 1) as $index) {
print_r($stat = $zip-statIndex($index));
$zip-extractTo('.', array($stat['name']));
echo $zip-getStatusString(), PHP_EOL;
}
$zip-close();
Outputs ...
Array
(
[name] = WavPack.wav
[index] = 0
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 45366
[comp_method] = 97
)
Compression method not supported
Array
(
[name] = PPMD.wav
[index] = 1
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 100729
[comp_method] = 98
)
Compression method not supported
Array
(
[name] = LZMA.wav
[index] = 2
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 68162
[comp_method] = 14
)
Compression method not supported
Array
(
[name] = BZIP2.wav
[index] = 3
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 104633
[comp_method] = 12
)
Compression method not supported
As you can see, 98, 97, 14 and 12 are all identified as the comp_method
(correctly). None of these compression methods are supported by php_zip,
but the constants should be present to allow determination of the method
used.
Interestingly WavPack was the best algorithm to use on uncompressed
audio (which WinZip performed when I asked it to compress to the
smallest size).
I can send the zip file if needed (300K).
I think it is important to remember that the zip files being accessed by
php_zip may not have been produced by php_zip.
[2011-01-28 11:34:43] paj...@php.net
If they are not implemented, no, it does not make sense to have them
exposed. If
one uses them he will then expect the compression mode to be set and
used
accordingly.
However for reading archive and get information about a given
compression mode,
yes. But only if they are actually used and set by libzip. If not,
please revert
this change.
[2011-01-28 11:22:37] rquadl...@php.net
As the compression mechanisms are stored within the zip file itself, it
isn't
necessarily a requirement for php_zip to support
compression/decompression of these
types, just identification.
Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA,
CM_BZIP and
CM_WAVPACK compressions.
Still looking for LZ77 and Terse.
The compression types are correctly identified by php_zip, so having the
constants
makes sense to me.
I'll update the documentation to say that whilst identification of these
types is
performed, compression and decompression of these types is not currently
supported.
[2011-01-28 07:43:12] paj...@php.net
Are you sure all compression modes are implemented? I don't think they
are, afair
that's also why I did not add them.
[2011-01-28 05:19:55] ahar...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53854
--
Edit this bug report at http://bugs.php.net/bug.php?id=53854edit=1
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1
ID: 53854
Updated by: rquadl...@php.net
Reported by:rquadl...@php.net
Summary:Missing constants for compression type.
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: n/a
PHP Version:5.3SVN-2011-01-27 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Just as an aside, the error constants that ARE documented ... I can see
no way to
generate them. None of the methods or functions in php_zip return an
error
constant. Should these be removed?
Previous Comments:
[2011-01-28 12:06:05] paj...@php.net
That's what I asked. We can keep them only and only if libzip detects
AND uses
these compression types correctly. It seems to be the case. Can you
confirm it and
maybe add a test per compression method?
[2011-01-28 12:03:35] rquadl...@php.net
I took a file (an uncompressed WAV file) and compressed it using WinZip
V15 using different algorithms.
Using the following code ...
?php
$zip = new ZipArchive;
$zip-open('wav.zipx');
foreach(range(0, $zip-numFiles - 1) as $index) {
print_r($stat = $zip-statIndex($index));
$zip-extractTo('.', array($stat['name']));
echo $zip-getStatusString(), PHP_EOL;
}
$zip-close();
Outputs ...
Array
(
[name] = WavPack.wav
[index] = 0
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 45366
[comp_method] = 97
)
Compression method not supported
Array
(
[name] = PPMD.wav
[index] = 1
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 100729
[comp_method] = 98
)
Compression method not supported
Array
(
[name] = LZMA.wav
[index] = 2
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 68162
[comp_method] = 14
)
Compression method not supported
Array
(
[name] = BZIP2.wav
[index] = 3
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 104633
[comp_method] = 12
)
Compression method not supported
As you can see, 98, 97, 14 and 12 are all identified as the comp_method
(correctly). None of these compression methods are supported by php_zip,
but the constants should be present to allow determination of the method
used.
Interestingly WavPack was the best algorithm to use on uncompressed
audio (which WinZip performed when I asked it to compress to the
smallest size).
I can send the zip file if needed (300K).
I think it is important to remember that the zip files being accessed by
php_zip may not have been produced by php_zip.
[2011-01-28 11:34:43] paj...@php.net
If they are not implemented, no, it does not make sense to have them
exposed. If
one uses them he will then expect the compression mode to be set and
used
accordingly.
However for reading archive and get information about a given
compression mode,
yes. But only if they are actually used and set by libzip. If not,
please revert
this change.
[2011-01-28 11:22:37] rquadl...@php.net
As the compression mechanisms are stored within the zip file itself, it
isn't
necessarily a requirement for php_zip to support
compression/decompression of these
types, just identification.
Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA,
CM_BZIP and
CM_WAVPACK compressions.
Still looking for LZ77 and Terse.
The compression types are correctly identified by php_zip, so having the
constants
makes sense to me.
I'll update the documentation to say that whilst identification of these
types is
performed, compression and decompression of these types is not currently
supported.
[2011-01-28 07:43:12] paj...@php.net
Are you sure all compression modes are implemented? I don't think they
are, afair
that's also why I did not add them.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53854
--
Edit this bug report at http://bugs.php.net/bug.php?id=53854edit=1
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1
ID: 53854
Updated by: paj...@php.net
Reported by:rquadl...@php.net
Summary:Missing constants for compression type.
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: n/a
PHP Version:5.3SVN-2011-01-27 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Let try to keep this discussion sane...:
We can keep them only if it is supported at least to read the
information about
an entry. For example, if an entry uses LZ77, then doing a stat/reading
the info
MUST return CW_LZ77.
If that's not the case, then we must remove them as it makes no sense to
expose
them to the user.
Is it more clear now? :)
Previous Comments:
[2011-01-28 12:11:02] rquadl...@php.net
Just as an aside, the error constants that ARE documented ... I can see
no way to
generate them. None of the methods or functions in php_zip return an
error
constant. Should these be removed?
[2011-01-28 12:06:05] paj...@php.net
That's what I asked. We can keep them only and only if libzip detects
AND uses
these compression types correctly. It seems to be the case. Can you
confirm it and
maybe add a test per compression method?
[2011-01-28 12:03:35] rquadl...@php.net
I took a file (an uncompressed WAV file) and compressed it using WinZip
V15 using different algorithms.
Using the following code ...
?php
$zip = new ZipArchive;
$zip-open('wav.zipx');
foreach(range(0, $zip-numFiles - 1) as $index) {
print_r($stat = $zip-statIndex($index));
$zip-extractTo('.', array($stat['name']));
echo $zip-getStatusString(), PHP_EOL;
}
$zip-close();
Outputs ...
Array
(
[name] = WavPack.wav
[index] = 0
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 45366
[comp_method] = 97
)
Compression method not supported
Array
(
[name] = PPMD.wav
[index] = 1
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 100729
[comp_method] = 98
)
Compression method not supported
Array
(
[name] = LZMA.wav
[index] = 2
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 68162
[comp_method] = 14
)
Compression method not supported
Array
(
[name] = BZIP2.wav
[index] = 3
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 104633
[comp_method] = 12
)
Compression method not supported
As you can see, 98, 97, 14 and 12 are all identified as the comp_method
(correctly). None of these compression methods are supported by php_zip,
but the constants should be present to allow determination of the method
used.
Interestingly WavPack was the best algorithm to use on uncompressed
audio (which WinZip performed when I asked it to compress to the
smallest size).
I can send the zip file if needed (300K).
I think it is important to remember that the zip files being accessed by
php_zip may not have been produced by php_zip.
[2011-01-28 11:34:43] paj...@php.net
If they are not implemented, no, it does not make sense to have them
exposed. If
one uses them he will then expect the compression mode to be set and
used
accordingly.
However for reading archive and get information about a given
compression mode,
yes. But only if they are actually used and set by libzip. If not,
please revert
this change.
[2011-01-28 11:22:37] rquadl...@php.net
As the compression mechanisms are stored within the zip file itself, it
isn't
necessarily a requirement for php_zip to support
compression/decompression of these
types, just identification.
Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA,
CM_BZIP and
CM_WAVPACK compressions.
Still looking for LZ77 and Terse.
The compression types are correctly identified by php_zip, so having the
constants
makes sense to me.
I'll update the documentation to say that whilst identification of these
types is
performed, compression and decompression of these types is not currently
supported.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53854
--
Edit this bug report at http://bugs.php.net/bug.php?id=53854edit=1
[PHP-BUG] Req #53866 [NEW]: Zend engine's hashtable performance tweaks
From: Operating system: PHP version: trunk-SVN-2011-01-28 (SVN) Package: Arrays related Bug Type: Feature/Change Request Bug description:Zend engine's hashtable performance tweaks Description: What was done: - Hash function in zend_hash.h was rebuilt and became much faster, without losing the most important properties. - Hashtable implementation was changed from Simple chaining to Open addressing with linear probing, but with linked bucket, not included in hash array, which causes: -- Bucket structure to lose 2 pointers. -- Searching works similar, but don't have to jump with pointers stored in different memory locations, inserting, deleting and rehashing don't need to update linked list, but must search for first empty bucket, which is fast, because it scans continuous memory. -- Load factor decreases from 1.0 to 0.5-0.75 to make less collisions and faster hashtable, which in turn increases memory footprint a little. - Open addressing doesn't change significantly performance, but next thing was to create new array (arEmpty), which is of size nTableSize bytes, which keeps track of used/empty buckets and makes inserting and rehashing much faster. In future it can be tested as bit-array with size of nTableSize/8 bytes. - More macros were added to replace repetitive constructs. - New constants were added to allow: -- Creating new hashtables of size at least X (where 4 and 8 are reasonable), which makes no rehashing and reallocing memory while changing size to 2 and then to 4. -- For small tables it's better to extend them by a factor of 4 times, not 2, to make rehashing cost smaller for most hashtables, of cost of little higher memory consumption. -- For large tables it's better to have other load factor, closer to 1, while for small tables it's better to use load factor closer to 0.5. What should be done: - http://lxr.php.net/xref/PHP_TRUNK/ext/standard/html_tables/html_table_gen.php#722 should be changed and html_tables.h regenerated, but this will need to rewrite hashtable engine from C to PHP - APC should be fixed What can be done: - Make new constants configurable by php.ini. - Test if changing arEmpty from byte-array to bit-array helps on performance. - Tweak default constants' values using some real-live benchmarks. - Prove (or modify and prove) hash function to have property, that it has no collisions if two keys don't differ on no more than 6 bytes, which will lead to memcmp omit first (or last) 6 bytes of key. Also simpler thing may be proven, that is it has no collisions if two keys are not longer than 6 bytes, which will make most string keys omit memcpy at all. -- Edit bug report at http://bugs.php.net/bug.php?id=53866edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53866r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53866r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53866r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53866r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53866r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53866r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53866r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53866r=needscript Try newer version: http://bugs.php.net/fix.php?id=53866r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53866r=support Expected behavior: http://bugs.php.net/fix.php?id=53866r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53866r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53866r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53866r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53866r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53866r=dst IIS Stability: http://bugs.php.net/fix.php?id=53866r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53866r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53866r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53866r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53866r=mysqlcfg
Bug #53865 [Com]: (float)0 * -1 = minus zero (-0)
Edit report at http://bugs.php.net/bug.php?id=53865edit=1 ID: 53865 Comment by: abc at abc dot abc Reported by:dmitrij at stepanov dot lv Summary:(float)0 * -1 = minus zero (-0) Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Oracle went crapping all over the Sun website a few months ago and broke tons of links. PHP bug reviewers give so little attention to each bug that they're still giving template replies to each bogus float bug with the same broken link. The correct answer to your problem is that this is a feature of the (IEEE 754) floating-point format. It supports positive and negative zero. The example you gave is behaving exactly as it should. Previous Comments: [2011-01-28 11:33:54] dmitrij at stepanov dot lv I guess the link should be http://en.wikipedia.org/wiki/IEEE_754 [2011-01-28 11:23:02] der...@php.net Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . [2011-01-28 10:03:40] dmitrij at stepanov dot lv Description: See test script. Test script: --- var_dump( (float)0 * -1); Expected result: float(0) Actual result: -- float(-0) -- Edit this bug report at http://bugs.php.net/bug.php?id=53865edit=1
Bug #53333 [Fbk]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5edit=1 ID: 5 Updated by: paj...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: Windows PHP Version:5.3.5 Assigned To:mysql Block user comment: N Private report: N New Comment: ok, can you please at least say if there is someone in your team able to deal with a dump? We can try to work together to solve it. This bug is preventing us to run daily automated QA tests. It is a stopping and is also filling our bugs databases from many users. Previous Comments: [2011-01-26 12:41:16] paj...@php.net On a shorter note, do you really have nobody able to deal with a dump? That's really the way to go with such bug and we spent already a fair amount of time to get all the possible details. The next step should really be a mysql developer sitting down and analyze the dump to see the condition where it happens. Please note that this bug is not really random as it happens on a regular basis, I got a couple of users reporting it as well. Is there anything else that you need to begin to work on it? Except a small reproduce script, can't produce one at this stage. [2011-01-22 04:31:35] kriscr...@php.net I believe it would also be helpful to allow the mysqlnd debug setting to be used on a non-debug PHP build as well. [2011-01-22 04:28:47] kriscr...@php.net Sorry for not keeping these comments up-to-date. I've had my head buried triaging this for the last two months now. Anyway, there's a few things to cover. First, I was able to get your mysqlnd debug to work. However, because you have it outputting the debug to a file on each and every PHP run, this filesystem stress is creating a major bottleneck, bringing PHP's perf understress down from around 50 tps (transactions per second) to about 1 or 2 tps. As a result, I am unable to repro this crash with this enabled as you specified in your comment. I would recommend that you perhaps find a way to store this data as an object or whatever and only output to a file in the event of a crash or other error. In any case, I spent some time backtracing this and I believe what we're dealing with is a classic double-free and/or corruption. I have no explanation as to what's causing the corruption to begin with though. I also investigated whether or not this is a threading issue. Contrary to what common sense would suggest, this does not appear to be the case, either. I ran the stress test again on Apache with the -X option (Debug mode), which forces httpd.exe to run as a single process. The crash still occured. No relevant change in the repro. I have also confirmed that this bug is still present in the latest release of 5.3.5. Finally, given the difficulty in reproducing this bug, not to mention the general difficulty in tracking down memory corruption issues in ANSI C in general, I'm now trying a bandaid approach. I added an ifcheck to _zend_mm_free_int in zend_alloc.c at the spot of the top of the crash stack, forcing it to skip the free attempt if the variable in question (next_block) is NULL. I then added some exception handling (using setjmp.h) code to mysqli_result_free_storage in mysqli.c at a spot earlier in the stack, forcing it to throw a PHP warning error (which is set to output to a log file) if there's an exception. I've never tried this in ANSI C before but I think I've got it right. The test is running now and may take awhile to yield a result. I will post a patch early next week. If successful, this won't fix whatever the underlying cause of the corruption is, but it will at least throw an error and spare us a crash, which will allow me to start generating PHP perf results under stress conditions along with the standard perf data. I'll post again when I have the results of this latest test run. [2010-12-02 11:26:33] paj...@php.net You need a debug build to get it working. [2010-12-02 08:45:42] kriscr...@php.net Unfortunately, still no go with the forward slashes. Has this new debug feature actually been tested yet, or perhaps it needs to be enabled in the source then rebuilt? I'm fresh out of ideas. :/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at
Bug #40787 [Com]: Error trying to insert into a CLOB column when using multi-byte charset.
Edit report at http://bugs.php.net/bug.php?id=40787edit=1 ID: 40787 Comment by: john dot doe at trash-mail dot com Reported by:jarismar at adplabs dot com dot br Summary:Error trying to insert into a CLOB column when using multi-byte charset. Status: Assigned Type: Bug Package:PDO related PHP Version:5.2.1 Assigned To:sixd Block user comment: N Private report: N New Comment: Is there any workaround or alternative for PHP 5.2.6 which is stable on Debian Lenny or is PDO not usable on this version? (I mean not usable because without fetching affected rows of INSERT, UPDATE, DELTE statements it's nearly impossible to write secure code). Previous Comments: [2010-05-26 15:05:16] firegun at thehummels dot org I`m having the same problem described here, I´m using the Doctrine library, running on lastest php version (5.3+) and oracle XE, with the charset AL32UTF8. Any ideas on a working solution? Comeon guys this is a 2007 bug... ;/ [2009-11-02 20:35:05] paj...@php.net Assigned it to someone more active :) [2009-11-02 20:06:16] markus at computino dot de Still a valid bug, cost me multiple hours trying to work it out before I found the bug report. Now using adodb/oci8. [2009-04-30 19:57:19] jarismar at adplabs dot com dot br Status changed to open again. [2009-04-30 19:44:03] jarismar at gmail dot com Infortunately this error persists, it still occurs. Tested with PHP Version : 5.2.10-dev Build Date : Apr 26 2009 23:39:22 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=40787 -- Edit this bug report at http://bugs.php.net/bug.php?id=40787edit=1
[PHP-BUG] Bug #53867 [NEW]: Test failure.
From: rquadling Operating system: Windows XP SP3 PHP version: 5.3SVN-2011-01-28 (SVN) Package: Zip Related Bug Type: Bug Bug description:Test failure. Description: The ext/zip/tests/stream_meta_data.phpt test fails on windows. The issue is in the URI test. zip:///%stest_with_comment.zip#foo I read this as ... stream zip:// root / path %s file#query test_with_comments.zip#foo On Windows the root is incorrect. It will be C: or D: (for example). As the path is picked up using %s, the attached patch should work on non-windows as well as windows. -- Edit bug report at http://bugs.php.net/bug.php?id=53867edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53867r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53867r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53867r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53867r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53867r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53867r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53867r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53867r=needscript Try newer version: http://bugs.php.net/fix.php?id=53867r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53867r=support Expected behavior: http://bugs.php.net/fix.php?id=53867r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53867r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53867r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53867r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53867r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53867r=dst IIS Stability: http://bugs.php.net/fix.php?id=53867r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53867r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53867r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53867r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53867r=mysqlcfg
Bug #53860 [Bgs]: unexpected behaviour in 'foreach' syntax checking
Edit report at http://bugs.php.net/bug.php?id=53860edit=1
ID: 53860
User updated by:soriasoft at gmail dot com
Reported by:soriasoft at gmail dot com
Summary:unexpected behaviour in 'foreach' syntax checking
Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
ok, but, $key and $value(the iteration variables) still living out of
the foreach loop code, and make this really hard to debug. In other
languages, this don't happens.
May be for you, is not an error, but some notice of this isn't a bad
idea.
Previous Comments:
[2011-01-27 22:21:52] ras...@php.net
There is no syntax error there though.
foreach(...); is a valid loop construct and { expr; } is also a valid
construct
on its own.
[2011-01-27 21:41:41] soriasoft at gmail dot com
Description:
I found and unexpected behavior in the syntax checking. When you write a
';' after the open brace, the parser doesn't display an error or notice
message, and executes the code with the last element of the array. I
test this in php5.3 and php5.2.
This innocent ; is realy hard to debug.
The enviroments:
joac@pepino ~/ReposGcoop $ php -v
PHP 5.3.3 with Suhosin-Patch (cli) (built: Jul 25 2010 12:50:19)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
debdev@jaula:~/www$ php -v
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010
03:25:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
Test script:
---
?php
function show_array($data_array){
foreach ($data_array as $key=$value);
{
print $key = $value\n;
if ( is_array( $value ) ){
show_array1( $value );
print End of nested Array\n;
}
}
};
$evil_array = array (
'item1' = array ( 'item1_1' = array( 'item1_1_1' = 1,
'item1_1_2' = 2 ),
'item1_2' = array( 'item1_2_1' = 3,),
),
'item2' = '4');
show_array($evil_array);
?
Output:
joac@pepino ~/ReposGcoop $ php bugphp.php
item2 = 4
Expected result:
I expect some error or notice for this syntax error.
Actual result:
--
joac@pepino ~/ReposGcoop $ php bugphp.php
item2 = 4
--
Edit this bug report at http://bugs.php.net/bug.php?id=53860edit=1
Req #52052 [Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052edit=1 ID: 52052 User updated by:ef-lists at email dot de Reported by:ef-lists at email dot de Summary:add syslog support to FPM Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux/*NIX PHP Version:5.3SVN-2010-06-11 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: Hi, added a new patch, which can be applied to a vanilla PHP 5.3.5. compiles and runs with: --enable-debug without relevant warnings --enable-maintainer-zts without other flags with having HAVE_SYSLOG_H in main/php_config.h undefined changes: * modified patch to work with FPM in 5.3.5 * added new parameters to config dump (todo: translate syslog prio and facility to nice human-readable values) * made comparing syslog facilities case-insensitive * replaced syslog() calls with php_syslog() Regards, Edgar Previous Comments: [2011-01-12 16:15:58] ef-lists at email dot de Hi Jerome, are there any updates on this issue yet? With PHP 5.3.4 and PHP 5.3.5 the latest patch doesn't work anymore. I'd be willing to port it to the latest release, if you're interested. I'd still like to see this integrated into trunk and 5.3.X. Regards, Edgar [2010-07-22 23:37:45] f...@php.net some answers to your questions: 1- this is a bug. All comparaison should use strcasecmp so that users can type facilities and log level with the case they want. 2- you're right. php_syslog() should be used instead of syslog() 4- after testing and validating, yes of course. I need to take time reviewing all this. Thx again ! [2010-07-07 13:17:07] f...@php.net Thanks for the reporting. I'll check that and answer you as soon as possible. [2010-07-07 12:27:54] ef-lists at email dot de Sorry it took me so long to reply. Too much work and too few spare time. Netherless I reviewed the patch and fixed some problems. If trace failed in fpm_php_trace.c:fpm_php_trace, there was a call to fwrite with a NULL pointer. Added syslog here. In fpm_stdio.c:fpm_stdio_init_child a close was performed on the fd set to ZLOG_SYSLOG. (valgrind complained) In fpm_stio.c:fpm_stdio_open_error_log, the variable syslog shadowed syslog() - renamed it to syslog_opened. It didn't matter from the code's point of view, but I think shadowing is a bad thing and renaming avoids it and also doesn't emit a warning, if you compile with -Wshadow. In php-fpm.conf.in was a typo (syslog_syslog_level - slowlog_syslog_level). Four more questions regarding the patch: 1) Is there a particular reason, why the facility names are partially compared with strcasecmp and strcmp? I found it confusing, that I have to type LOCAL6 instead of local6. 2) When looking at php_syslog.h - for maximum portability, shouldn't the syslog() calls be changed to php_syslog()? 3) I'm unsure - but aren't we losing messages from libevent written to stderr in the master process? I think one could use the fpm event system, to catch stderr, but didn't investigate further yet. 4) Are you planning to integrate this patch into SVN? Oh and besides the issues I mentioned - the patch works fine for me. :-) Regards, Edgar [2010-06-13 11:03:33] f...@php.net my mistakes. The v2 patch was buggy. Use v3 instead. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052edit=1
Req #47872 [Com]: PHP 5.3+ support for namespace wildcards (use statement)
Edit report at http://bugs.php.net/bug.php?id=47872edit=1
ID: 47872
Comment by: iffzy at atomar dot de
Reported by:kwutzke at web dot de
Summary:PHP 5.3+ support for namespace wildcards (use
statement)
Status: Bogus
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: all
PHP Version:5.3.0RC1
Block user comment: N
Private report: N
New Comment:
It may be a major slowdown when used by idiots.
But sometimes this limitation it a major nuisance.
I don't need a f*g nanny for this :/
(yeah I know.. I should silently switch to python.. feels like flogging
a dead horse..)
Previous Comments:
[2009-04-03 19:40:40] johan...@php.net
We have no class loading mechanism like Java but need the class names
while compiling the PHP script. Offering an import foo\* would be a a
major slowdown.
[2009-04-02 02:55:05] kwutzke at web dot de
Another option, which I can't quite assess, would be to always
(silently) use the root namespace. For some reason I don't believe this
is a good idea in PHP. Maybe because, as seen in my example, is the
ability to expand the root/global namespace with other (own) classes.
[2009-04-02 02:50:20] kwutzke at web dot de
Other examples of use wildcards are:
use \namespace2\*;
use \otherns\*;
use \myown\sub\*;
use \myown\sub\subsub\*;
[2009-04-02 02:44:11] kwutzke at web dot de
Description:
When using namespaces you always have to put the exact 'use \ClassName'
statement into the code. This list of dependencies can become quite
large in some classes. To relieve programmers from having to manually
put use statements to the top (or elsewhere) a namespace wildcard should
be added to the language.
Much like in Java, where in stead of writing
import java.awt.Image;
import javax.swing.JTextField;
import javax.swing.JComboBox;
import javax.swing.JSpinner;
import javax.swing.JCheckBox;
import javax.swing.JRadioButton;
import javax.swing.JMenuItem;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
one could write
import java.awt.*;
import javax.swing.*;
This saves a lot of time while writing the code. An IDE (plugin) might
replace the wildcards with the actually used classes.
Wrting
use \*;
seems natural to me. Don't know how much this RFE is possible
language-wise. It would however make lots of sense for PHP 5.3.
I'm not sure if this is the right place to ask for a language
enhancement of this caliber.
Reproduce code:
---
?php
namespace whatever; //in dir whatever
//use \*; - why not???
//PHP standard classes
use \Exception;
//ZF classes
use \Zend_Version;
class ZfTools
{
public static function checkVersion($strRequiredVersion = '1.5.1')
{
switch ( Zend_Version::compareVersion($strRequiredVersion) )
{
case -1: //required is older
return true;
case 0: //equal
case 1: //newer
return false;
default: //should never be executed
throw new Exception('Error comparing Zend
Framework version!');
}
}
}
?
Expected result:
use \*;
would compile so that Zend_Version and Exception can be used without
leading backslashes.
Actual result:
--
use \*;
Generates a parse error Parse error: parse error, expecting `T_STRING'
in C:\dev\apache\htdocs\whatever\ZfTools.php on line 5
--
Edit this bug report at http://bugs.php.net/bug.php?id=47872edit=1
[PHP-BUG] Bug #53868 [NEW]: typo in php crashed server
From: Operating system: windows 7 PHP version: 5.3.5 Package: Apache related Bug Type: Bug Bug description:typo in php crashed server Description: I was using a recursive directory program and made a typo in my ignore array $ignore = array( 'cgi-bin','robots','ocasional-cards.co.uk','New Holder'.'.', '..',); when it should have been $ignore = array( 'cgi-bin','robots','ocasional-cards.co.uk','New Folder','.', '..',); ethen everytime i run the program apahe server stopped workingI am nor sur e if this is a bug but thought i would let you guys know just in case Test script: --- as above if you need more info please email me Expected result: program to run Actual result: -- server crash -- Edit bug report at http://bugs.php.net/bug.php?id=53868edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53868r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53868r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53868r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53868r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53868r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53868r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53868r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53868r=needscript Try newer version: http://bugs.php.net/fix.php?id=53868r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53868r=support Expected behavior: http://bugs.php.net/fix.php?id=53868r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53868r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53868r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53868r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53868r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53868r=dst IIS Stability: http://bugs.php.net/fix.php?id=53868r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53868r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53868r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53868r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53868r=mysqlcfg
Bug #53868 [Opn-Bgs]: typo in php crashed server
Edit report at http://bugs.php.net/bug.php?id=53868edit=1 ID: 53868 Updated by: sala...@php.net Reported by:s_cardwell at btinternet dot com Summary:typo in php crashed server -Status: Open +Status: Bogus Type: Bug Package:Apache related Operating System: windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: No comment. Previous Comments: [2011-01-28 17:25:08] s_cardwell at btinternet dot com Description: I was using a recursive directory program and made a typo in my ignore array $ignore = array( 'cgi-bin','robots','ocasional-cards.co.uk','New Holder'.'.', '..',); when it should have been $ignore = array( 'cgi-bin','robots','ocasional-cards.co.uk','New Folder','.', '..',); ethen everytime i run the program apahe server stopped workingI am nor sur e if this is a bug but thought i would let you guys know just in case Test script: --- as above if you need more info please email me Expected result: program to run Actual result: -- server crash -- Edit this bug report at http://bugs.php.net/bug.php?id=53868edit=1
[PHP-BUG] Bug #53869 [NEW]: Random Segmentation Fault (11)
From:
Operating system: FreeBSD 7.4
PHP version: 5.3.5
Package: Apache2 related
Bug Type: Bug
Bug description:Random Segmentation Fault (11)
Description:
I was getting random Segfaults in my httpd-error.log. Occurred rarely
(about 12-20 times a day on a site that has about 200,000 page views a
day). Narrowed the problem down to calls to virtual(). I had 3 to 4 per
page. Changing virtual() out with include() or require() completely
removed segfaults.
Apache 2.2.17
PHP 5.3.5 from FreeBSD ports (did not occur when using PHP 5.2.17 from
source).
Loaded symbols for /libexec/ld-elf.so.1
#0 0x28adf4f1 in _zval_ptr_dtor (zval_ptr=0xbfbfd23c,
__zend_filename=0x28c61a48
/usr/ports/lang/php5/work/php-5.3.5/Zend/zend_execute.h,
__zend_lineno=318) at zend.h:385
385 zend.h: No such file or directory.
in zend.h
[New Thread 0x28501040 (LWP 100269)]
(gdb) bt full
#0 0x28adf4f1 in _zval_ptr_dtor (zval_ptr=0xbfbfd23c,
__zend_filename=0x28c61a48
/usr/ports/lang/php5/work/php-5.3.5/Zend/zend_execute.h,
__zend_lineno=318) at zend.h:385
No locals.
#1 0x28b1d1fd in zend_vm_stack_clear_multiple () at zend_execute.h:318
q = (zval *) 0x0
p = (void **) 0x29924ab8
delete_count = 686419922
#2 0x28b1dc33 in zend_do_fcall_common_helper_SPEC
(execute_data=0x29924040) at zend_vm_execute.h:406
opline = (zend_op *) 0x28e9bc2c
should_change_scope = 0 '\0'
#3 0x28b22758 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x29924040) at zend_vm_execute.h:1606
opline = (zend_op *) 0x28e9bc2c
fname = (zval *) 0x28e9bc48
#4 0x28b1ca6b in execute (op_array=0x28e9f0a0) at zend_vm_execute.h:107
ret = 0
execute_data = (zend_execute_data *) 0x29924040
nested = 1 '\001'
original_in_execution = 0 '\0'
#5 0x28af0557 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/ports/lang/php5/work/php-5.3.5/Zend/zend.c:1194
files = 0xbfbfd404
i = 1
file_handle = (zend_file_handle *) 0xbfbfe934
orig_op_array = (zend_op_array *) 0x0
orig_retval_ptr_ptr = (zval **) 0x0
#6 0x28a843ad in php_execute_script (primary_file=0xbfbfe934) at
/usr/ports/lang/php5/work/php-5.3.5/main/main.c:2265
realfile =
¥¤¬(ìSé(\230eé(l\000\000\000\020\000\000\000\220\214[(Ã\aÃ¥(\bå¿¿\230ì(\000\214[(\024Té(\200à Ã
(©\001,
'\0' repeats 14 times,
\004ì(\024eé(\021\000\000\000Ãä¿¿¥¤¬(xö\002\000\v\000\000\000\021\000\000\000Ãä¿¿y§¬(
ö\002\000
ö\002\000\021\000\000\000\024\216[(`yé(|yé(T,\003\000\021\000\000\000Ã\aÃ¥(ð\020ø(\004ì(´yé(TÃÃ(\004\000\000\000\bå¿¿y§¬(\b,\003\000\b,\003\000\210yé(\000\000\000\000\021\000\000\0008å¿¿¥¤¬(`yé(X\000\000\000...
__orig_bailout = (sigjmp_buf *) 0xbfbfe970
__bailout = {{_sjb = {682115418, 0, -1077947412, -1077942008, 0,
-1077942100, 4735, -1077942168, 682556027, 684203328,
682590304, 0}}}
prepend_file_p = (zend_file_handle *) 0x0
append_file_p = (zend_file_handle *) 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0,
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {
handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf =
0x0, old_handle = 0x0, old_closer = 0}, reader = 0,
fsizer = 0, closer = 0}}, free_filename = 0 '\0'}
append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0,
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {
handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf =
0x0, old_handle = 0x0, old_closer = 0}, reader = 0,
fsizer = 0, closer = 0}}, free_filename = 0 '\0'}
old_cwd = 0xbfbfd420 /
use_heap = 0 '\0'
---Type return to continue, or q return to quit---
retval = 0
#7 0x28bbbd73 in php_handler (r=0x29918058) at
/usr/ports/lang/php5/work/php-5.3.5/sapi/apache2handler/sapi_apache2.c:669
zfd = {type = ZEND_HANDLE_MAPPED, filename = 0x29919828
/usr/home/yyy/public_html/folder/page.php, opened_path = 0x0,
handle = {fd = 686393184, fp = 0x28e98760, stream = {handle = 0x28e98760,
isatty = 0, mmap = {len = 11011, pos = 0, map = 0x0,
buf = 0x295fd000 Address 0x295fd000 out of bounds, old_handle =
0x0, old_closer = 0},
reader = 0x28a9bab0 _php_stream_read, fsizer = 0x28a825e0
php_zend_stream_fsizer,
closer = 0x28a825c0 php_zend_stream_mmap_closer}}, free_filename =
0 '\0'}
__orig_bailout = (sigjmp_buf *) 0x0
__bailout = {{_sjb = {683391806, 0, -1077942004, -1077941800, 0,
686098368, 4735, 676142160, 676141696, 686099352,
-1077941800, 0}}}
ctx = (php_struct * volatile) 0x2991c3f0
conf = (void *) 0x28e4f858
brigade = (apr_bucket_brigade * volatile) 0x2991cb18
bucket = (apr_bucket *) 0x2854c760
rv = 676135291
parent_req = (request_rec *
[PHP-BUG] Bug #53870 [NEW]: Problem with passing array elements as references in foreach
From:
Operating system: Mac OS X Snow Leopard
PHP version: 5.3.5
Package: Arrays related
Bug Type: Bug
Bug description:Problem with passing array elements as references in foreach
Description:
I created an array of strings that would be typecast to integers, and cast
them using a foreach loop, passing each element by reference. After
dumping the resulting array, it gave (somewhat) expected results, though
after dumping each element individually, it gave an unexpected result on
the last element.
This happened with PHP 5.3.5 on Mac OS X Snow Leopard, but did not happen
on a Debian system with PHP 5.2.6.
Test script:
---
?php
$array = array('1', '2', '5324', '435', '51');
foreach($array as $element){
$element = (int)$element;
}
var_dump($array);
foreach($array as $key = $element){
var_dump($key);
var_dump($element);
echo \n;
}
?
Expected result:
array(6) {
[0]=
int(1)
[1]=
int(2)
[2]=
int(3)
[3]=
int(5324)
[4]=
int(435)
[5]=
int(51)
}
int(0)
int(1)
int(1)
int(2)
int(2)
int(3)
int(3)
int(5324)
int(4)
int(435)
int(5)
int(51)
Actual result:
--
array(6) {
[0]=
int(1)
[1]=
int(2)
[2]=
int(3)
[3]=
int(5324)
[4]=
int(435)
[5]=
int(51)
}
int(0)
int(1)
int(1)
int(2)
int(2)
int(3)
int(3)
int(5324)
int(4)
int(435)
int(5)
int(435)
--
Edit bug report at http://bugs.php.net/bug.php?id=53870edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53870r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53870r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53870r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53870r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53870r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53870r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53870r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53870r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53870r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53870r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53870r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53870r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53870r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53870r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53870r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53870r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53870r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53870r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53870r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53870r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53870r=mysqlcfg
Bug #53850 [Fbk-Opn]: openssl_pkey_export() with password not protecting private key
Edit report at http://bugs.php.net/bug.php?id=53850edit=1
ID: 53850
User updated by:jason dot gerfen at gmail dot com
Reported by:jason dot gerfen at gmail dot com
Summary:openssl_pkey_export() with password not protecting
private key
-Status: Feedback
+Status: Open
Type: Bug
Package:OpenSSL related
Operating System: arch linux x86_64
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I have verified this under the following conditions.
Arch Linux x86_64 installation
This configuration returns a password protected private key
Apache 2.2 [./configure]
OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-0.9.8q
--shared]
PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-0.9.8q]
This configuration however does not return a password protected key
Apache 2.2 [./configure]
OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-1.0.0c
--shared]
PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-1.0.0c]
Anything else you might find pertinent?
Previous Comments:
[2011-01-26 20:12:04] paj...@php.net
There is no different code in php to deal with this function.
If two versions of openssl give you two different results then it is a
openssl
problem, not php.
Also I would like you to test using the same PHP versions vs two
openssl, then we
can begin to discuss a possible issue. Be sure to use the latest
versions
available at php.net, not the centos (or any other distro) you use.
[2011-01-26 20:04:50] jason dot gerfen at gmail dot com
Description:
I have tested this against php5.3.5 with OpenSSL 1.0.0c (arch linux) vs
an older server running php5.2.14 with OpenSSL 0.9.8e (centos linux).
Test script:
---
$opts = array('config'='openssl.cnf',
'encrypt_key'=true,
'private_key_type'=OPENSSL_KEYTYPE_RSA,
'digest_alg'='sha256',
'private_key_bits'=2048,
'x509_extensions'='usr_cert');
$handle = openssl_pkey_new($opts);
openssl_pkey_export($handle, $privatekey, sha1($_SERVER['REMOTE_ADDR']),
$opts);
echo $privatekey;
Expected result:
CentOS example output
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C93B386451093918
buV1Kuaiu8QXhSeBdAF9Le2u+SSzaEtrHw6rLq19xL+9lWuwf4dFtrMPRI/PPvA5
HwBB7ZzT1AAzOAK2AnDiND3+n6IyqrkQjD7R0bGY6VLXdMr3qgGiJOkmsroF5t/H
LQEFGn9F8eOfEQTjkz4h9KYF/traXZSayBjNQ37fL42HO4M5WY0Ehms6bfeU5BN5
1d+NdENKLK0KVIJDNM3clQoHCc2KJwq70CeZmKq+tIG7UdigxmW0f9B/BMSM8PFx
3cFzt1eZVj23jPO65icEfqLWvdYUpOqFfZc17Si87LW8ExvO8yu4UPrk8iRR8eFH
LeOCPobR446Ehq8XBgFiFp8kzus5vDbqRLbMaBqul/mVWDmkpcyrnWJVAfginUar
FDTji8Ge8Zv5GgpuS2tjYkQpykthA17SKxDGe8s26feaHkErEanTWg5o50RP1oUo
1e2rrX+PVFoukN9f+j5OiScC8QDVfBcSZZYvfRmkE1SnF3S3CAVdtDIcqmy33WY+
Icx/n2uh3Y4tYafzSu/5O8ZeBzGUz3eKWMIAL66mxOclPAceWsQ6Ry22IBdjr+7p
Af3IKo4sWVtj3mOlrwNdNX9JtdHYiskNTVJ7+7DBlmbM+lfQlvb7wBsVek9ex6k2
qxWv250S+rdWuXBx3WuleQsQ14gBtX7Rf0Sk3DvOTinaU9C5n8xwaO9GWS0CJtjA
AkDTLZ0rylVjfdd3W7fjxfYtQEwnbKeIC1SEKuNR8tv6GXGuubU5Nt8Q5TIhZIYL
p2H027lafTE1Ky+KIRD0qZWfSEAujrxJVnH1n62edYxzWXfr+onS0g==
-END RSA PRIVATE KEY-
Actual result:
--
Arch linux sample output
-BEGIN ENCRYPTED PRIVATE KEY-
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIkd4I9LadOsYCAggA
MBQGCCqGSIb3DQMHBAhqJEWqm0xA9ASCAoDgWeRhfyKrCqfW7aSW1rYs8LVjN3ug
p9Kn6U7YZydHwxYdwNSK80i0yw+yU+ovVck2BdCBnm8ggdyXgS5UVTt5bnJHIHls
rEe4spLl8hkc0sOcL/ZseVBoxKIan7ZY1c0AysAwmrniFXKehSTCByDMUC58rl6H
gejVJk4+yebHuLqeq7z9d9dIvEuAFI9qjZjqUhq8wsCdN2+scFi/3/DXDp1V5/AS
SCeIsVsvcBNPaI8CYP48R13+mQJ+AGAWewcoHtwu8IQGuG46vlqOaYULCfInr/w7
/Y+Ttd2Hd6RHcnE9vTW7bhOn49v6KCtcwpcAtSz2kHrAufGxjAMzFV2oEVZPsDGM
4Rf3H1JtlJKIFYktTLoz9/07kQR0c6S1UkBa2oG/O7G0in7igzQEafKPKOMdOo3j
jP23He7kHJTTja5HE41DryUwa1JIB4L/BtbLDiYJA7KcrY7WoSROL675OmJEG1v6
vjLD0kcxIqc4rT0xesv4JEwVBxh8R/1qlqJjvLGJU8UQYWAzLqiMsg2rqrAy9XQy
Eu53GLXKhKCV2NtuvVQMbvza3RajA77B2i/EEM/ORKGiDI9isHce2yM4hptggBU6
YZiqOzIcgYjo1Dv/IB069jUdxXUg874MD/MG9r1ERUsZrLX8UMyVVj7VmnH6tMsc
2S/YwCgvflRdubDEJdmTE8KUD6XSTUjhdy1Tqzzhfg3KZ8SI8Bknb4k1oV8pSAlC
9YezxiisH4FL041LpUGhj9lbvHtY+8ctxbAT35Jy6npK94rASmoOXt0TFcOJxoGn
xCZjstibMOzNSNFU8subS92Xsu9fWtEV+nCAgDOtJeMwqFNBE1g5e6JN
-END ENCRYPTED PRIVATE KEY-
--
Edit this bug report at http://bugs.php.net/bug.php?id=53850edit=1
Bug #53867 [Opn-Csd]: Test failure.
Edit report at http://bugs.php.net/bug.php?id=53867edit=1 ID: 53867 Updated by: fel...@php.net Reported by:rquadl...@php.net Summary:Test failure. -Status: Open +Status: Closed Type: Bug Package:Zip Related Operating System: Windows XP SP3 PHP Version:5.3SVN-2011-01-28 (SVN) -Assigned To: +Assigned To:felipe 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-01-28 21:41:55] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307829 Log: - Fixed bug #53867 (Test failure) patch by: rquadling at php.net [2011-01-28 15:20:19] rquadl...@php.net Description: The ext/zip/tests/stream_meta_data.phpt test fails on windows. The issue is in the URI test. zip:///%stest_with_comment.zip#foo I read this as ... stream zip:// root / path %s file#query test_with_comments.zip#foo On Windows the root is incorrect. It will be C: or D: (for example). As the path is picked up using %s, the attached patch should work on non-windows as well as windows. -- Edit this bug report at http://bugs.php.net/bug.php?id=53867edit=1
Sec Bug-Bug #53864 [Opn-Bgs]: the end
Edit report at http://bugs.php.net/bug.php?id=53864edit=1 ID: 53864 Updated by: fel...@php.net Reported by:zeegirl87 at yahoo dot com Summary:the end -Status: Open +Status: Bogus -Type: Security +Type: Bug Package:Filter related Operating System: ubuntu PHP Version:5.2.17 -Block user comment: N +Block user comment: Y Private report: Y New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2011-01-28 09:31:54] zeegirl87 at yahoo dot com Description: --- From manual page: http://www.php.net/function.pdf-begin-document#Description --- -- Edit this bug report at http://bugs.php.net/bug.php?id=53864edit=1
Req #53866 [Opn-Asn]: Zend engine's hashtable performance tweaks
Edit report at http://bugs.php.net/bug.php?id=53866edit=1 ID: 53866 Updated by: fel...@php.net Reported by:marcin dot babij at nasza-klasa dot pl Summary:Zend engine's hashtable performance tweaks -Status: Open +Status: Assigned Type: Feature/Change Request -Package:Arrays related +Package:Scripting Engine problem PHP Version:trunk-SVN-2011-01-28 (SVN) -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2011-01-28 13:27:48] marcin dot babij at nasza-klasa dot pl Description: What was done: - Hash function in zend_hash.h was rebuilt and became much faster, without losing the most important properties. - Hashtable implementation was changed from Simple chaining to Open addressing with linear probing, but with linked bucket, not included in hash array, which causes: -- Bucket structure to lose 2 pointers. -- Searching works similar, but don't have to jump with pointers stored in different memory locations, inserting, deleting and rehashing don't need to update linked list, but must search for first empty bucket, which is fast, because it scans continuous memory. -- Load factor decreases from 1.0 to 0.5-0.75 to make less collisions and faster hashtable, which in turn increases memory footprint a little. - Open addressing doesn't change significantly performance, but next thing was to create new array (arEmpty), which is of size nTableSize bytes, which keeps track of used/empty buckets and makes inserting and rehashing much faster. In future it can be tested as bit-array with size of nTableSize/8 bytes. - More macros were added to replace repetitive constructs. - New constants were added to allow: -- Creating new hashtables of size at least X (where 4 and 8 are reasonable), which makes no rehashing and reallocing memory while changing size to 2 and then to 4. -- For small tables it's better to extend them by a factor of 4 times, not 2, to make rehashing cost smaller for most hashtables, of cost of little higher memory consumption. -- For large tables it's better to have other load factor, closer to 1, while for small tables it's better to use load factor closer to 0.5. What should be done: - http://lxr.php.net/xref/PHP_TRUNK/ext/standard/html_tables/html_table_gen.php#722 should be changed and html_tables.h regenerated, but this will need to rewrite hashtable engine from C to PHP - APC should be fixed What can be done: - Make new constants configurable by php.ini. - Test if changing arEmpty from byte-array to bit-array helps on performance. - Tweak default constants' values using some real-live benchmarks. - Prove (or modify and prove) hash function to have property, that it has no collisions if two keys don't differ on no more than 6 bytes, which will lead to memcmp omit first (or last) 6 bytes of key. Also simpler thing may be proven, that is it has no collisions if two keys are not longer than 6 bytes, which will make most string keys omit memcpy at all. -- Edit this bug report at http://bugs.php.net/bug.php?id=53866edit=1
Bug #52713 [Opn-Csd]: Can't call undefined methods (using __call) on parent
Edit report at http://bugs.php.net/bug.php?id=52713edit=1 ID: 52713 Updated by: fel...@php.net Reported by:michael at wakeless dot net Summary:Can't call undefined methods (using __call) on parent -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: All PHP Version:5.3.3 -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: Yes, it has been already fixed in 5.3.4. Thanks. Previous Comments: [2011-01-11 17:52:14] ghosh at q-one dot com Is this still problem with PHP 5.3.4? Following the discussion here: http://www.serverphorums.com/read.php?7,220473,220473#msg-220473 it seems this should already been fixed. This bug, however, is still marked as open. [2010-08-31 14:48:25] giovanni at giacobbi dot net @michael: I think the situation is perfectly clear. I think they screwed up on this one. @felipe: this change is absolutely not reasonable and breaks backward compatibility. I understand that the behaviour for #51176 is inconvenient, but that's the way it is, you cannot change this in a minor release. My suggestion (and wish) is that you revert this change to the previous behaviour. Shall we discuss this in the internals mailing list? Sounds like an interesting issue without a straightforward solution.giov [2010-08-31 06:06:45] michael at wakeless dot net I'm pretty sure everyone should be aware of this but I'll say it nonetheless. parent:: isn't necessarily a static call. When it's used within an object context it should remain within an object context, but the subsequent call to __callStatic seems to lose it. I tried a workaround of testing for $this in __callStatic but it seems to have gone missing. Is there anything I can do to help this out? Write a more comprehensive test case that can be checked into the suite? [2010-08-31 01:06:05] fel...@php.net The change was introduced as a fix for the bug #51176. [2010-08-31 01:05:07] fel...@php.net The difference introduced was that the __call() just will be called when __callStatic() is not implemented, on such static method calls. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52713 -- Edit this bug report at http://bugs.php.net/bug.php?id=52713edit=1
Bug #53807 [Opn-Fbk]: Apache CRASH (getopt)
Edit report at http://bugs.php.net/bug.php?id=53807edit=1
ID: 53807
Updated by: fel...@php.net
Reported by:hm at mail dot ru
Summary:Apache CRASH (getopt)
-Status: Open
+Status: Feedback
Type: Bug
Package:Output Control
Operating System: WINDOWS XP SP3 x86
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Previous Comments:
[2011-01-21 22:39:32] hm at mail dot ru
Description:
Apache is restarting (crash) after launch the script in browser.
Test script:
---
?php
$options = getopt('t:d:e:l');
Expected result:
Crash apache
--
Edit this bug report at http://bugs.php.net/bug.php?id=53807edit=1
[PHP-BUG] Bug #53872 [NEW]: internal corruption of phar
From: Operating system: Windows 7 32-bit PHP version: 5.3.5 Package: PHAR related Bug Type: Bug Bug description:internal corruption of phar Description: internal corruption of phar, when reading file from phar archive has size equal to zero Test script: --- http://host0001.webd.pl/bugs/php/internal_corruption_of_phar.zip Expected result: testcase.php from internal_corruption_of_phar.zip should prints OK Actual result: -- testcase.php from internal_corruption_of_phar.zip prints OK internal corruption of phar -- Edit bug report at http://bugs.php.net/bug.php?id=53872edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53872r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53872r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53872r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53872r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53872r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53872r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53872r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53872r=needscript Try newer version: http://bugs.php.net/fix.php?id=53872r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53872r=support Expected behavior: http://bugs.php.net/fix.php?id=53872r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53872r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53872r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53872r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53872r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53872r=dst IIS Stability: http://bugs.php.net/fix.php?id=53872r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53872r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53872r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53872r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53872r=mysqlcfg
Bug #53748 [Opn-Csd]: Using traits lead to a segmentation fault
Edit report at http://bugs.php.net/bug.php?id=53748edit=1 ID: 53748 Updated by: fel...@php.net Reported by:contact at chdemko dot com Summary:Using traits lead to a segmentation fault -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Fedora core 11 PHP Version:trunk-SVN-2011-01-14 (SVN) -Assigned To: +Assigned To:felipe 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-01-28 22:19:11] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307832 Log: - Fixed bug #53748 (Using traits lead to a segmentation fault) [2011-01-24 11:30:56] karolrybak at gmail dot com I have the same problem. I don't have a test case, cause the bug happens randomly across application. I also get some corrupted variables filled with some random data. Here's the backtrace: #0 0x013795d8 in zval_mark_grey (pz=0x9c5c230) at /root/php-build/php-5.3.4/Zend/zend_gc.c:372 p = 0x1850005 #1 0x01379ebd in gc_mark_roots () at /root/php-build/php-5.3.4/Zend/zend_gc.c:435 No locals. #2 gc_collect_cycles () at /root/php-build/php-5.3.4/Zend/zend_gc.c:664 p = value optimized out q = value optimized out orig_free_list = value optimized out orig_next_to_free = value optimized out count = value optimized out #3 0x0135c115 in zend_deactivate () at /root/php-build/php-5.3.4/Zend/zend.c:900 No locals. #4 0x01303a8a in php_request_shutdown (dummy=0x0) at /root/php-build/php-5.3.4/main/main.c:1633 report_memleaks = 1 '\001' #5 0x013e7eff in php_apache_request_dtor (r=0x94be720) at /root/php-build/php-5.3.4/sapi/apache2handler/sapi_apache2.c:509 No locals. #6 php_handler (r=0x94be720) at /root/php-build/php-5.3.4/sapi/apache2handler/sapi_apache2.c:681 ctx = 0x94c4168 conf = 0x92b4e18 brigade = 0x94c9968 bucket = value optimized out rv = value optimized out parent_req = 0x0 ---Type return to continue, or q return to quit--- #7 0x003d2a4d in ap_run_handler () No symbol table info available. #8 0x003d63f8 in ap_invoke_handler () No symbol table info available. #9 0x003e253e in ap_process_request () No symbol table info available. #10 0x003df2df in ?? () No symbol table info available. #11 0x003da92d in ap_run_process_connection () No symbol table info available. #12 0x003daa2c in ap_process_connection () No symbol table info available. #13 0x003e6e24 in ?? () No symbol table info available. #14 0x003e7131 in ?? () No symbol table info available. #15 0x003e720a in ?? () No symbol table info available. #16 0x003e7d6b in ap_mpm_run () No symbol table info available. #17 0x003be157 in main () No symbol table info available. (gdb) Here's the configure script ./configure \ --build=i386-redhat-linux \ --host=i386-redhat-linux \ --target=i386-redhat-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --with-libdir=lib \ --with-config-file-path=/etc \ --with-config-file-scan-dir=/etc/php.d \ --disable-debug \ --with-pic \ --disable-rpath \ --with-pear \ --with-curl \ --with-exec-dir=/usr/bin \ --with-freetype-dir=/usr \ --without-gdbm \ --with-gettext \ --with-iconv \ --with-zlib \ --with-layout=GNU \ --enable-exif \ --enable-ftp \ --enable-magic-quotes \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-sysvmsg \ --enable-wddx \ --with-kerberos \ --enable-ucd-snmp-hack \ --without-unixODBC \ --enable-shmop \ --enable-calendar \ --with-apxs2=/usr/sbin/apxs \ --without-sqlite \ --enable-dom \ --disable-dba \ --enable-pdo \ --enable-xmlreader \ --enable-xmlwriter \ --with-xmlrpc \ --with-gd \ --with-openssl \ --with-libxml-dir=/usr \ --disable-cgi \ --enable-mbstring \ --enable-bcmath [2011-01-21 13:56:06] contact at chdemko dot com I've compiled php with --enable-debug This is the trace: bash-4.0$ gdb ./sapi/cli/php GNU gdb (GDB) Fedora (6.8.50.20090302-40.fc11) Copyright (C) 2009 Free
[PHP-BUG] Bug #53873 [NEW]: Bug in rand()
From: Operating system: Linux PHP version: 5.3.5 Package: *General Issues Bug Type: Bug Bug description:Bug in rand() Description: $codigo = rand(100,4294967295); El valor de $CODIGO fue: 81 - $codigo = rand(100,4294967295); the value of $CODIGO is: 81 --- From manual page: http://www.php.net/function.rand#Descripción --- Test script: --- $codigo = rand(100,4294967295); El valor de $CODIGO fue: 81 - $codigo = rand(100,4294967295); the value of $CODIGO is: 81 -- Edit bug report at http://bugs.php.net/bug.php?id=53873edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53873r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53873r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53873r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53873r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53873r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53873r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53873r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53873r=needscript Try newer version: http://bugs.php.net/fix.php?id=53873r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53873r=support Expected behavior: http://bugs.php.net/fix.php?id=53873r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53873r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53873r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53873r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53873r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53873r=dst IIS Stability: http://bugs.php.net/fix.php?id=53873r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53873r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53873r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53873r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53873r=mysqlcfg
Bug #53683 [Opn-Bgs]: Presence of __invoke makes protected __construct visible as callable
Edit report at http://bugs.php.net/bug.php?id=53683edit=1
ID: 53683
Updated by: fel...@php.net
Reported by:tomasz dot slominski at gmail dot com
Summary:Presence of __invoke makes protected __construct
visible as callable
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: Irrelevant
PHP Version:5.3.5
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
See your code, you are using is_callable('foo', 'bar') instead of
is_callable(array('foo', 'bar'))... :)
Previous Comments:
[2011-01-07 01:02:09] tomasz dot slominski at gmail dot com
Description:
Presence of __invoke causes is_callable($obj, '__construct') returns
true,
instead of false when it's called out of class scope.
Also, is_callable('class', '__construct') yields true even if
__construct is set
to protected (which is clearly not connected with __invoke issue, but I
suppose
that is caused by the same underlying problem).
Although setting __construct private/protected seems a little bit
pervert, if it
is not interdicted by language semantics, visibility testing should give
good
results.
Test script:
---
class Singleton {
protected static $aInstances = array();
final protected function __construct(){}
public static function getInstance(){
$sClassName = get_called_class();
if (!isset(static::$aInstances[$sClassName])) {
static::$aInstances[$sClassName] = new
$sClassName();
} // if
return static::$aInstances[$sClassName];
} // getInstance
} // class
class SingletonWithInvoke extends Singleton {
final protected function __invoke(){}
} // class
var_dump(is_callable(Singleton::getInstance(), '__construct'));
var_dump(is_callable(SingletonWithInvoke::getInstance(),
'__construct'));
var_dump(is_callable('Singleton', '__construct'));
var_dump(is_callable('SingletonWithInvoke', '__construct'));
Expected result:
bool(false) bool(false) bool(false) bool(false)
Actual result:
--
bool(false) bool(true) bool(true) bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53683edit=1
Bug #53873 [Opn-Bgs]: Bug in rand()
Edit report at http://bugs.php.net/bug.php?id=53873edit=1 ID: 53873 Updated by: fel...@php.net Reported by:noel_fb at hotmail dot com Summary:Bug in rand() -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: Linux PHP Version:5.3.5 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 This is because the 4294967295 is converted to long, hence... var_dump((int)4294967295); // int(-1) Previous Comments: [2011-01-28 22:26:24] noel_fb at hotmail dot com Description: $codigo = rand(100,4294967295); El valor de $CODIGO fue: 81 - $codigo = rand(100,4294967295); the value of $CODIGO is: 81 --- From manual page: http://www.php.net/function.rand#Descripción --- Test script: --- $codigo = rand(100,4294967295); El valor de $CODIGO fue: 81 - $codigo = rand(100,4294967295); the value of $CODIGO is: 81 -- Edit this bug report at http://bugs.php.net/bug.php?id=53873edit=1
[PHP-BUG] Req #53874 [NEW]: date_default_timezone_set() on header
From: Operating system: Windows x86 PHP version: 5.3.5 Package: Date/time related Bug Type: Feature/Change Request Bug description:date_default_timezone_set() on header Description: date_default_timezone_set() does not affect any HTTP-header? For example created with setcookie(), the setting has no effect. Why is PHP given It is not safe to rely on the system's timezone settings on date() but not on setcookie()? So if the method is used to correct the timezone (eg. GMT to GMT+1) no header generated by PHP will regarding the changed time. Any cookie set to 1 hour expiration will fail. If this is bogus, please add a warning to setcookie() linking with date_default_timezone_set(). -- Edit bug report at http://bugs.php.net/bug.php?id=53874edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53874r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53874r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53874r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53874r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53874r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53874r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53874r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53874r=needscript Try newer version: http://bugs.php.net/fix.php?id=53874r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53874r=support Expected behavior: http://bugs.php.net/fix.php?id=53874r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53874r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53874r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53874r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53874r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53874r=dst IIS Stability: http://bugs.php.net/fix.php?id=53874r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53874r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53874r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53874r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53874r=mysqlcfg
Req #53874 [Opn-Bgs]: date_default_timezone_set() on header
Edit report at http://bugs.php.net/bug.php?id=53874edit=1 ID: 53874 Updated by: scott...@php.net Reported by:frame at dynamiccreated dot de Summary:date_default_timezone_set() on header -Status: Open +Status: Bogus Type: Feature/Change Request Package:Date/time related Operating System: Windows x86 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: cookies are based on GMT and don't use a timezone. Previous Comments: [2011-01-28 23:09:41] frame at dynamiccreated dot de Description: date_default_timezone_set() does not affect any HTTP-header? For example created with setcookie(), the setting has no effect. Why is PHP given It is not safe to rely on the system's timezone settings on date() but not on setcookie()? So if the method is used to correct the timezone (eg. GMT to GMT+1) no header generated by PHP will regarding the changed time. Any cookie set to 1 hour expiration will fail. If this is bogus, please add a warning to setcookie() linking with date_default_timezone_set(). -- Edit this bug report at http://bugs.php.net/bug.php?id=53874edit=1
Bug #43817 [Com]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817edit=1 ID: 43817 Comment by: asankel at yahoo dot com Reported by:losd at mail dot dk Summary:opendir() fails on Windows directories with parent directory unaccessible Status: Assigned Type: Bug Package:Directory function related Operating System: win32 only - Windows Server 2003 PHP Version:5.3.0beta1 Assigned To:pajoye Block user comment: N Private report: N New Comment: Same problem with PHP 5.3.5 on Windows 2008 with IIS 7. Workaround is to add \. to the end of the path and then PHP doesn't attempt to access the parent directories at all. For example, change d:\files\directory\test to d:\files\directory\test\. Previous Comments: [2010-04-08 16:36:02] dani...@php.net That makes sense. I'm on XP. Thanks. If you need quicker feedback, shoot me an email or assign the bug to me. [2010-04-05 01:59:43] paj...@php.net Nothing has changed in 5.2/3.x about that. The problem may come from the tsrm's real path which tries to access all parent directories to cache them. I have to investigate why it fails on XP (and on on 2003 for your right?) but not on more recent versions. [2010-04-05 01:45:01] dani...@php.net I just installed 5.3.2. The regression has gotten worse. Now the Subdir/.. workaround fails too: Warning: opendir(C:/Dir/Subdir/..,C:/Dir/Subdir/..) [function.opendir]: Access is denied. (code: 5)... [2010-03-29 00:27:55] paj...@php.net Please try with 5.3.2 [2010-03-29 00:12:25] dani...@php.net Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817edit=1
Bug #43817 [Com]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817edit=1 ID: 43817 Comment by: asankel at yahoo dot com Reported by:losd at mail dot dk Summary:opendir() fails on Windows directories with parent directory unaccessible Status: Assigned Type: Bug Package:Directory function related Operating System: win32 only - Windows Server 2003 PHP Version:5.3.0beta1 Assigned To:pajoye Block user comment: N Private report: N New Comment: Never mind on the workaround. Was related to some fastcgi caching. If you are running fastcgi the parent directory check is only done the first time. If it has access the first time it won't check the parent directory for further accesses. Previous Comments: [2011-01-29 00:11:37] asankel at yahoo dot com Same problem with PHP 5.3.5 on Windows 2008 with IIS 7. Workaround is to add \. to the end of the path and then PHP doesn't attempt to access the parent directories at all. For example, change d:\files\directory\test to d:\files\directory\test\. [2010-04-08 16:36:02] dani...@php.net That makes sense. I'm on XP. Thanks. If you need quicker feedback, shoot me an email or assign the bug to me. [2010-04-05 01:59:43] paj...@php.net Nothing has changed in 5.2/3.x about that. The problem may come from the tsrm's real path which tries to access all parent directories to cache them. I have to investigate why it fails on XP (and on on 2003 for your right?) but not on more recent versions. [2010-04-05 01:45:01] dani...@php.net I just installed 5.3.2. The regression has gotten worse. Now the Subdir/.. workaround fails too: Warning: opendir(C:/Dir/Subdir/..,C:/Dir/Subdir/..) [function.opendir]: Access is denied. (code: 5)... [2010-03-29 00:27:55] paj...@php.net Please try with 5.3.2 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817edit=1
[PHP-BUG] Bug #53875 [NEW]: file() fgets() fgetc() will read ?php but not save this
From:
Operating system: Windows XP
PHP version: 5.3.5
Package: Streams related
Bug Type: Bug
Bug description:file() fgets() fgetc() will read ?php but not save this
Description:
If reading a file that contains ? this is ignored and any text
afterwards on that line is ignored.
?php - does not read
? php - does not read
??
Even with extra spaces before the ? gets shifted to the next line.
The fgetc reads the line and can show the data but lines read with the
file() command ignores the line.
Test script:
---
Two files required: phpinfo2.php
?php - does not read
phpinfo();
?
?
?php - does not read
? php - does not read
?
Second file: readFileViaPHP.php
?
$lines = file('phpinfo2.php',FILE_IGNORE_NEW_LINES|FILE_SKIP_EMPTY_LINES);
echo 'pre';
print_r ($lines);
echo '/pre';
echo 'br /' . \n;
?
Expected result:
You should see all records from phpinfo2.php
Array
(
[0] = ?php - does not read
[1] = phpinfo();
[2] = ?
[3] =?
[4] = ?php - does not read
[5] = ? php - does not read
[6] = ?
)
Actual result:
--
Array
(
[0] = phpinfo();
[2] = ?
[5] =?
)
--
Edit bug report at http://bugs.php.net/bug.php?id=53875edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53875r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53875r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53875r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53875r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53875r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53875r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53875r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53875r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53875r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53875r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53875r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53875r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53875r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53875r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53875r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53875r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53875r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53875r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53875r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53875r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53875r=mysqlcfg
Bug #53875 [Opn-Bgs]: file() fgets() fgetc() will read ?php but not save this
Edit report at http://bugs.php.net/bug.php?id=53875edit=1
ID: 53875
Updated by: scott...@php.net
Reported by:rosshowatson at gmail dot com
Summary:file() fgets() fgetc() will read ?php but not save
this
-Status: Open
+Status: Bogus
Type: Bug
Package:Streams related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
It's be interpreted as HTML tags, hence why it goes 0, 2, 5.
add
header('Content-Type: text/plain'); to the top or click view source.
Previous Comments:
[2011-01-29 00:31:53] rosshowatson at gmail dot com
Description:
If reading a file that contains ? this is ignored and any text
afterwards on that line is ignored.
?php - does not read
? php - does not read
??
Even with extra spaces before the ? gets shifted to the next line.
The fgetc reads the line and can show the data but lines read with the
file() command ignores the line.
Test script:
---
Two files required: phpinfo2.php
?php - does not read
phpinfo();
?
?
?php - does not read
? php - does not read
?
Second file: readFileViaPHP.php
?
$lines =
file('phpinfo2.php',FILE_IGNORE_NEW_LINES|FILE_SKIP_EMPTY_LINES);
echo 'pre';
print_r ($lines);
echo '/pre';
echo 'br /' . \n;
?
Expected result:
You should see all records from phpinfo2.php
Array
(
[0] = ?php - does not read
[1] = phpinfo();
[2] = ?
[3] =?
[4] = ?php - does not read
[5] = ? php - does not read
[6] = ?
)
Actual result:
--
Array
(
[0] = phpinfo();
[2] = ?
[5] =?
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53875edit=1
Req #53779 [Opn]: New class ReflectionConstant along the lines of ReflectionProperty
Edit report at http://bugs.php.net/bug.php?id=53779edit=1 ID: 53779 Updated by: fel...@php.net Reported by:RQuadling at GMail dot com Summary:New class ReflectionConstant along the lines of ReflectionProperty Status: Open Type: Feature/Change Request Package:Reflection related Operating System: Irrelevant PHP Version:5.3SVN-2011-01-18 (SVN) Block user comment: N Private report: N New Comment: More related ideas in bug #45569 Previous Comments: [2011-01-18 16:55:51] RQuadling at GMail dot com Description: Using ReflectionClass-getConstants() returns all constants defined in the class tree as a simple array, irrespective of the defining class. In comparison to that ReflectionClass-getProperties() returns a collection of ReflectionProperty, allowing you to filter the find the properties for a single class. So, would it be possible to have a similar mechanism for constants, replacing the simplistic array with a collection of RefelctionConstant. -- Edit this bug report at http://bugs.php.net/bug.php?id=53779edit=1
Bug #53875 [Bgs]: file() fgets() fgetc() will read ?php but not save this
Edit report at http://bugs.php.net/bug.php?id=53875edit=1
ID: 53875
User updated by:rosshowatson at gmail dot com
Reported by:rosshowatson at gmail dot com
Summary:file() fgets() fgetc() will read ?php but not save
this
Status: Bogus
Type: Bug
Package:Streams related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I have tried adding the header('Content-Type: text/plain'); statement to
both the main PHP program and the source that it is reading but get the
same results. I have taken the phpinfo2.php file and renamed this to
phpinfo.txt with the same result.
Just now I decided to examine the HTML source code and it does DOES SHOW
THE CODE correctly.
THE BUG IS NOT IN PHP. THE BUG IS IN IE8. In Opera it works
correctly.
The cause is Micr0$0ft.
The data is in what is sent to the browser, the browser fails to read
the HTML correctly and drops lines here there and everywhere.
Work around for IE8 only:
$lines =
file('phpinfo2.txt',FILE_IGNORE_NEW_LINES|FILE_SKIP_EMPTY_LINES);
$lines = str_replace(, lt;, $lines); // replace the with lt;
Close the problem/bug as no fix required.
Previous Comments:
[2011-01-29 01:11:17] scott...@php.net
It's be interpreted as HTML tags, hence why it goes 0, 2, 5.
add
header('Content-Type: text/plain'); to the top or click view source.
[2011-01-29 00:31:53] rosshowatson at gmail dot com
Description:
If reading a file that contains ? this is ignored and any text
afterwards on that line is ignored.
?php - does not read
? php - does not read
??
Even with extra spaces before the ? gets shifted to the next line.
The fgetc reads the line and can show the data but lines read with the
file() command ignores the line.
Test script:
---
Two files required: phpinfo2.php
?php - does not read
phpinfo();
?
?
?php - does not read
? php - does not read
?
Second file: readFileViaPHP.php
?
$lines =
file('phpinfo2.php',FILE_IGNORE_NEW_LINES|FILE_SKIP_EMPTY_LINES);
echo 'pre';
print_r ($lines);
echo '/pre';
echo 'br /' . \n;
?
Expected result:
You should see all records from phpinfo2.php
Array
(
[0] = ?php - does not read
[1] = phpinfo();
[2] = ?
[3] =?
[4] = ?php - does not read
[5] = ? php - does not read
[6] = ?
)
Actual result:
--
Array
(
[0] = phpinfo();
[2] = ?
[5] =?
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53875edit=1
