Bug #55524 [Asn]: Traits should not be able to extend a class
Edit report at https://bugs.php.net/bug.php?id=55524&edit=1
ID: 55524
Updated by: g...@php.net
Reported by:g...@php.net
Summary:Traits should not be able to extend a class
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4.0alpha3
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Checking for interface is already done. As well as checking that classes do not
extend traits. I only missed checking that traits do not extend classes, as far
as
I can tell. Plan to fix it later this week.
Previous Comments:
[2011-08-29 01:03:01] ka...@php.net
Might also be worth checking the implements keyword if a user tries to
implement an interface (or multiple)
[2011-08-28 08:05:04] g...@php.net
Description:
Spotted by this post: http://zuttonet.com/articles/php-class-traits/
Traits build their own hierarchy of uses, but there is no useful semantics for
extending classes.
For instance:
trait Foo extends Base {
function bar() {}
}
The semantics for that is not defined (and actually at least broken for
abstract
methods).
This should give a fatal error as would the other way around (Base extends Foo).
Test script:
---
trait Foo extends Base {
function bar() {}
}
Expected result:
Fatal error: A trait (Foo) cannot extend a class (Base) in %s on line %d
--
Edit this bug report at https://bugs.php.net/bug.php?id=55524&edit=1
Req #48080 [Opn]: Add support for forcing DOM to validate a DOMDocument with a DTD
Edit report at https://bugs.php.net/bug.php?id=48080&edit=1 ID: 48080 Updated by: cataphr...@php.net Reported by:jose dot rob dot jr at gmail dot com Summary:Add support for forcing DOM to validate a DOMDocument with a DTD Status: Open Type: Feature/Change Request Package:DOM XML related PHP Version:5.2.9 Block user comment: N Private report: N New Comment: Added libxml_set_external_entity_loader() in PHP 5.4/trunk, which also solves this problem. Previous Comments: [2010-10-31 12:49:50] php at example dot com It should also be noted that this affects any DOMDocuments using the standard XHTML SystemIDs. The W3C decided to block all requests to their URIs. See http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic [2009-04-26 17:17:38] jose dot rob dot jr at gmail dot com Description: I need to validate XML files before loading them, then I created a DTD and hosted it. With python I can distribute the DTD file with the program and validate the XML file locally. A python example: --- from lxml import etree from StringIO import StringIO xmlstart=""" http://example.com/mydtd.dtd'>""" xmlok=xmlstart+"The XML file"; xmlinvalid=xmlstart+"testThe XML file"; dtddata=""; f=StringIO(dtddata); dtd=etree.DTD(f); print "Valid XML:"; xml1=etree.XML(xmlok); validation=dtd.validate(xml1); print validation; print dtd.error_log.filter_from_errors(); print "Invalid XML:"; xml2=etree.XML(xmlinvalid); validation=dtd.validate(xml2); print validation; print dtd.error_log.filter_from_errors(); The only way I find to port this stript is using DOMDocument::validate() but this method will get the DTD from http://example.com/mydtd.dtd and be slower, generate traffic, and fail when example.com is off-line... I suggest adding an attribute like DOMDocument::validate($source) where $source is a string with DTD source to avoid situations like this... Reproduce code: --- http://example.com/mydtd.dtd'> XML; $xmlok=$xmlstart."The XML file"; $xmlinvalid=$xmlstart."testThe XML file"; $dtddata=""; print "Valid XML:"; $xml1=DOMDocument::loadXML($xmlok); $validation=(int)$xml1->validate($dtddata); //Example that would work print "$validation"; print "Invalid XML:"; $xml1=DOMDocument::loadXML($xmlinvalid); $validation=(int)$xml1->validate($dtddata); //Example that would work print "$validation"; ?> Expected result: Valid XML: 1 Invalid XML: Warning: DOMDocument::validate() [function.DOMDocument-validate]: Element example was declared #PCDATA but contains non text nodes in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: No declaration for element a in /script/path/xml.php on line 19 0 Actual result: -- When no argument is passed to validate and DTD server is off-line: Valid XML: Warning: DOMDocument::validate(http://example.com/mydtd.dtd) [function.DOMDocument-validate]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 14 Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O warning : failed to load external entity "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 14 Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could not load the external subset "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 14 0 Invalid XML: Warning: DOMDocument::validate(http://example.com/mydtd.dtd) [function.DOMDocument-validate]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: I/O warning : failed to load external entity "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 19 Warning: DOMDocument::validate() [function.DOMDocument-validate]: Could not load the external subset "http://example.com/mydtd.dtd"; in /script/path/xml.php on line 19 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=48080&edit=1
Bug #55510 [Fbk->Ver]: $_FILES 'name' missing first character after upload.
Edit report at https://bugs.php.net/bug.php?id=55510&edit=1
ID: 55510
Updated by: ar...@php.net
Reported by:aaron at gwmicro dot com
Summary:$_FILES 'name' missing first character after upload.
-Status: Feedback
+Status: Verified
Type: Bug
Package:Filesystem function related
Operating System: Windows Server 2008 R2
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This bug is present on Windows with magic_quotes_gpc on. "s" is then always set
and the change in r312103 means the leading char is skipped.
Previous Comments:
[2011-08-29 02:43:24] ar...@php.net
The following patch has been added/updated:
Patch Name: fix-upload-win-mqgpc-bug-55510.patch
Revision: 1314585804
URL:
https://bugs.php.net/patch-display.php?bug=55510&patch=fix-upload-win-mqgpc-bug-55510.patch&revision=1314585804
[2011-08-28 17:38:32] aaron at gwmicro dot com
I started going back version by version from 5.3.8 to see where the problem
started, and it seems to have begun with 5.3.7, as 5.3.6 works correctly. Once
again, I'm just replacing PHP builds -- I'm not modifying any else. With 5.3.6,
I get back what I would expect:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
With 5.3.7 and 5.3.8, I get back the missing first letter:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "eadme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
With 5.4.beta1-dev, I'm back to getting everything that I expect:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
[2011-08-28 17:21:37] aaron at gwmicro dot com
Here are the capture contents using Wireshark and PHP 5.3.8:
No. TimeSourceDestination Protocol Length
Info
1203 7.25209310.0.0.251184.18.147.3 HTTP 986
POST /private/aaron/filename.php HTTP/1.1 (text/plain)
Frame 1203: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb), Dst: 3com_49:bb:06
(00:01:02:49:bb:06)
Internet Protocol Version 4, Src: 10.0.0.251 (10.0.0.251), Dst: 184.18.147.3
(184.18.147.3)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80),
Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary:
"---9503744825200"
[Type: multipart/form-data]
First boundary: -9503744825200\r\n
Encapsulated multipart part: (text/plain)
Content-Disposition: form-data; name="filename";
filename="readme.txt"\r\n
Content-Type: text/plain\r\n\r\n
Line-based text data: text/plain
Hello! This is a test.
Last boundary: \r\n-9503744825200--\r\n
No. TimeSourceDestination Protocol Length
Info
1205 7.25278210.0.0.1 10.0.0.251HTTP 986
POST /private/aaron/filename.php HTTP/1.1 (text/plain)
Frame 1205: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: 3com_49:bb:06 (00:01:02:49:bb:06), Dst: AsustekC_8e:2f:bb
(00:26:18:8e:2f:bb)
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.251
(10.0.0.251)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80),
Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary:
"---9503744825200"
[Type: multipart/form-data]
First boundary: -9503744825200\r\n
Encapsulated multipart part: (text/plain)
Content-Disposition: form-data; name="filename";
filename="readme.txt"\r\n
Content-Type: text/plain\r\n\r\n
Line-based text data: text/plain
Hello! This is a test.
Last boundary: \r\n-9503744825200--\r\n
[2011-08-26 23:02:34] johan...@php.net
Keeping state at "Feedback" until data requested by mafick is provided.
[2011-08-26 20:46:53] aaron at gwmicro dot com
Yes, I will attempt to
Bug #55510 [PATCH]: $_FILES 'name' missing first character after upload.
Edit report at https://bugs.php.net/bug.php?id=55510&edit=1
ID: 55510
Patch added by: ar...@php.net
Reported by:aaron at gwmicro dot com
Summary:$_FILES 'name' missing first character after upload.
Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: Windows Server 2008 R2
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix-upload-win-mqgpc-bug-55510.patch
Revision: 1314585804
URL:
https://bugs.php.net/patch-display.php?bug=55510&patch=fix-upload-win-mqgpc-bug-55510.patch&revision=1314585804
Previous Comments:
[2011-08-28 17:38:32] aaron at gwmicro dot com
I started going back version by version from 5.3.8 to see where the problem
started, and it seems to have begun with 5.3.7, as 5.3.6 works correctly. Once
again, I'm just replacing PHP builds -- I'm not modifying any else. With 5.3.6,
I get back what I would expect:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
With 5.3.7 and 5.3.8, I get back the missing first letter:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "eadme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
With 5.4.beta1-dev, I'm back to getting everything that I expect:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
[2011-08-28 17:21:37] aaron at gwmicro dot com
Here are the capture contents using Wireshark and PHP 5.3.8:
No. TimeSourceDestination Protocol Length
Info
1203 7.25209310.0.0.251184.18.147.3 HTTP 986
POST /private/aaron/filename.php HTTP/1.1 (text/plain)
Frame 1203: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb), Dst: 3com_49:bb:06
(00:01:02:49:bb:06)
Internet Protocol Version 4, Src: 10.0.0.251 (10.0.0.251), Dst: 184.18.147.3
(184.18.147.3)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80),
Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary:
"---9503744825200"
[Type: multipart/form-data]
First boundary: -9503744825200\r\n
Encapsulated multipart part: (text/plain)
Content-Disposition: form-data; name="filename";
filename="readme.txt"\r\n
Content-Type: text/plain\r\n\r\n
Line-based text data: text/plain
Hello! This is a test.
Last boundary: \r\n-9503744825200--\r\n
No. TimeSourceDestination Protocol Length
Info
1205 7.25278210.0.0.1 10.0.0.251HTTP 986
POST /private/aaron/filename.php HTTP/1.1 (text/plain)
Frame 1205: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: 3com_49:bb:06 (00:01:02:49:bb:06), Dst: AsustekC_8e:2f:bb
(00:26:18:8e:2f:bb)
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.251
(10.0.0.251)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80),
Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary:
"---9503744825200"
[Type: multipart/form-data]
First boundary: -9503744825200\r\n
Encapsulated multipart part: (text/plain)
Content-Disposition: form-data; name="filename";
filename="readme.txt"\r\n
Content-Type: text/plain\r\n\r\n
Line-based text data: text/plain
Hello! This is a test.
Last boundary: \r\n-9503744825200--\r\n
[2011-08-26 23:02:34] johan...@php.net
Keeping state at "Feedback" until data requested by mafick is provided.
[2011-08-26 20:46:53] aaron at gwmicro dot com
Yes, I will attempt to get this information to you. I can say that we were
using 5.2.13 without incident prior to updating to 5.3.8. After updating to
5.3.8, we were notified by users that they could no longer download files that
they were successfully uploading. That was when I determined the missing
Bug #55524 [Asn]: Traits should not be able to extend a class
Edit report at https://bugs.php.net/bug.php?id=55524&edit=1
ID: 55524
Updated by: ka...@php.net
Reported by:g...@php.net
Summary:Traits should not be able to extend a class
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4.0alpha3
Assigned To:gron
Block user comment: N
Private report: N
New Comment:
Might also be worth checking the implements keyword if a user tries to
implement an interface (or multiple)
Previous Comments:
[2011-08-28 08:05:04] g...@php.net
Description:
Spotted by this post: http://zuttonet.com/articles/php-class-traits/
Traits build their own hierarchy of uses, but there is no useful semantics for
extending classes.
For instance:
trait Foo extends Base {
function bar() {}
}
The semantics for that is not defined (and actually at least broken for
abstract
methods).
This should give a fatal error as would the other way around (Base extends Foo).
Test script:
---
trait Foo extends Base {
function bar() {}
}
Expected result:
Fatal error: A trait (Foo) cannot extend a class (Base) in %s on line %d
--
Edit this bug report at https://bugs.php.net/bug.php?id=55524&edit=1
[PHP-BUG] Bug #55527 [NEW]: DateTime::__construct throws Exception even when timezone is specified
From:
Operating system: Linux
PHP version: 5.3.8
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::__construct throws Exception even when timezone is
specified
Description:
The DateTime constructor throws an Exception warning that it is not safe to
rely
on the system's timezone settings if you try to construct a DateTime object
and
haven't somehow specified a timezone, whether by using
date_default_timezone_set,
the date.timezone setting, or the $timezone argument of DateTime itself.
However, there is another way to specify the timezone for a DateTime
object, by
passing a time string which includes a timezone as the first argument to
the
constructor. When such a string is given, the $timezone argument is ignored
and
the timezone given in the string is always used.
However, this doesn't prevent the Exception from being thrown, even though
a
timezone is being specified. To avoid the Exception, you have to have a
default
timezone set, or you have to pass a DateTimeZone as the second argument,
even
though neither would actually be used for creating the object.
Test script:
---
format('O');
} catch (Exception $e) {
echo 'Exception thrown.';
}
echo PHP_EOL;
date_default_timezone_set('America/New_York');
try {
$date = new DateTime('2011-08-28T00:00:00+');
echo $date->format('O');
} catch (Exception $e) {
echo 'Exception thrown.';
}
Expected result:
+
+
Actual result:
--
Exception thrown.
+
--
Edit bug report at https://bugs.php.net/bug.php?id=55527&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55527&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55527&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55527&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55527&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55527&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55527&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55527&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55527&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55527&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55527&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55527&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55527&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55527&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55527&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55527&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55527&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55527&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55527&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55527&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55527&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55527&r=mysqlcfg
Bug #30157 [Bgs->Tbd]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Updated by: paj...@php.net Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() -Status: Bogus +Status: To be documented Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: Hm, actually let move it as a to be documented instead Previous Comments: [2011-08-28 22:05:36] paj...@php.net . [2011-08-28 22:01:39] bugs dot php at mohiva dot com I think this bug can be closed. As described by Gustavo(http://news.php.net/php.internals/54999), this is by design. And the wrong results, described in the last comments, are errors in my stream wrapper implementation. [2011-08-28 10:53:37] bugs dot php at mohiva dot com >> Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. [2011-08-26 13:26:58] bugs dot php at mohiva dot com Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). >> Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157&edit=1
Bug #30157 [Opn->Bgs]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Updated by: paj...@php.net Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() -Status: Open +Status: Bogus Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: . Previous Comments: [2011-08-28 22:01:39] bugs dot php at mohiva dot com I think this bug can be closed. As described by Gustavo(http://news.php.net/php.internals/54999), this is by design. And the wrong results, described in the last comments, are errors in my stream wrapper implementation. [2011-08-28 10:53:37] bugs dot php at mohiva dot com >> Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. [2011-08-26 13:26:58] bugs dot php at mohiva dot com Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). >> Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? [2011-08-25 12:30:42] bugs dot php at mohiva dot com Two years later the bug is still present in 5.3.8 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157&edit=1
Bug #30157 [Com]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Comment by: bugs dot php at mohiva dot com Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Open Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: I think this bug can be closed. As described by Gustavo(http://news.php.net/php.internals/54999), this is by design. And the wrong results, described in the last comments, are errors in my stream wrapper implementation. Previous Comments: [2011-08-28 10:53:37] bugs dot php at mohiva dot com >> Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. [2011-08-26 13:26:58] bugs dot php at mohiva dot com Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). >> Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? [2011-08-25 12:30:42] bugs dot php at mohiva dot com Two years later the bug is still present in 5.3.8 [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157&edit=1
Bug #55336 [Opn->Fbk]: mail() function is not thread safe for Windows builds
Edit report at https://bugs.php.net/bug.php?id=55336&edit=1
ID: 55336
Updated by: paj...@php.net
Reported by:grabli_2005 at mail dot ru
Summary:mail() function is not thread safe for Windows
builds
-Status: Open
+Status: Feedback
Type: Bug
Package:Network related
Operating System: Windows
PHP Version:5.4.0alpha2
-Assigned To:
+Assigned To:pajoye
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.
Would rock if you can provide one.
Previous Comments:
[2011-08-28 20:16:31] grabli_2005 at mail dot ru
Yep, I`ve got buffer corruption and socket leak under threading.
There no need of TSRM code, socket handle and buffer can be allocated on stack,
it`s not so big (4kb).
[2011-08-22 14:51:22] ka...@php.net
Have you encountered any issues specific to this finding? I suppose we could
make a new globals, like PW32G for SendMail and stash the variables in there.
[2011-08-03 18:20:59] grabli_2005 at mail dot ru
switch status to open, see details in previous comment
[2011-08-01 13:40:27] grabli_2005 at mail dot ru
I`ve provide this patches as reference only, not as product quality code
replacement.
The only difference that I note since 5.3.0 is FormatEmailAddress function,
that omits <> around emails.
You can check my statment:
look at /ext/standard/mail.c function php_mail
Here nix path: sendmail = popen(sendmail_cmd, "w");
Here win32 path: if (TSendMail(INI_STR("SMTP"), &tsm_err, &tsm_errmsg, hdr,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {
TSendMail located in win32\sendmail.c
here global variables:
#ifndef THREAD_SAFE
char Buffer[MAIL_BUFFER_SIZE];
/* socket related data */
SOCKET sc;
#ifndef NETWARE
WSADATA Data;
struct hostent *adr;
int WinsockStarted;
/* values set by the constructor */
char *AppName;
#endif /* NETWARE */
SOCKADDR_IN sock_in;
char MailHost[HOST_NAME_LEN];
char LocalHost[HOST_NAME_LEN];
#endif
It`s placed under #ifndef THREAD_SAFE, but THREAD_SAFE not defined anywhere
even when compile with ZTS. More often _THREAD_SAFE used around the code.
If you define THREAD_SAFE it`s break sendmail.c compilation, because rest of
code uses this variables without any define switch.
You can simply debug or place debug printf() in TSendMail and see that this
code executed and uses global variables.
win32\time.c have same issue.
[2011-08-01 12:55:11] paj...@php.net
Please provide a patch against 5.3 and 5.4.
Also I'm not sure about your statement.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55336
--
Edit this bug report at https://bugs.php.net/bug.php?id=55336&edit=1
Bug #55336 [Opn]: mail() function is not thread safe for Windows builds
Edit report at https://bugs.php.net/bug.php?id=55336&edit=1
ID: 55336
User updated by:grabli_2005 at mail dot ru
Reported by:grabli_2005 at mail dot ru
Summary:mail() function is not thread safe for Windows
builds
Status: Open
Type: Bug
Package:Network related
Operating System: Windows
PHP Version:5.4.0alpha2
Block user comment: N
Private report: N
New Comment:
Yep, I`ve got buffer corruption and socket leak under threading.
There no need of TSRM code, socket handle and buffer can be allocated on stack,
it`s not so big (4kb).
Previous Comments:
[2011-08-22 14:51:22] ka...@php.net
Have you encountered any issues specific to this finding? I suppose we could
make a new globals, like PW32G for SendMail and stash the variables in there.
[2011-08-03 18:20:59] grabli_2005 at mail dot ru
switch status to open, see details in previous comment
[2011-08-01 13:40:27] grabli_2005 at mail dot ru
I`ve provide this patches as reference only, not as product quality code
replacement.
The only difference that I note since 5.3.0 is FormatEmailAddress function,
that omits <> around emails.
You can check my statment:
look at /ext/standard/mail.c function php_mail
Here nix path: sendmail = popen(sendmail_cmd, "w");
Here win32 path: if (TSendMail(INI_STR("SMTP"), &tsm_err, &tsm_errmsg, hdr,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {
TSendMail located in win32\sendmail.c
here global variables:
#ifndef THREAD_SAFE
char Buffer[MAIL_BUFFER_SIZE];
/* socket related data */
SOCKET sc;
#ifndef NETWARE
WSADATA Data;
struct hostent *adr;
int WinsockStarted;
/* values set by the constructor */
char *AppName;
#endif /* NETWARE */
SOCKADDR_IN sock_in;
char MailHost[HOST_NAME_LEN];
char LocalHost[HOST_NAME_LEN];
#endif
It`s placed under #ifndef THREAD_SAFE, but THREAD_SAFE not defined anywhere
even when compile with ZTS. More often _THREAD_SAFE used around the code.
If you define THREAD_SAFE it`s break sendmail.c compilation, because rest of
code uses this variables without any define switch.
You can simply debug or place debug printf() in TSendMail and see that this
code executed and uses global variables.
win32\time.c have same issue.
[2011-08-01 12:55:11] paj...@php.net
Please provide a patch against 5.3 and 5.4.
Also I'm not sure about your statement.
[2011-08-01 12:02:42] grabli_2005 at mail dot ru
fixed typo in title
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55336
--
Edit this bug report at https://bugs.php.net/bug.php?id=55336&edit=1
Req #55526 [Opn->Asn]: Heartbeat rate too high causes a lot of events
Edit report at https://bugs.php.net/bug.php?id=55526&edit=1 ID: 55526 Updated by: f...@php.net Reported by:adrien at antipoul dot fr Summary:Heartbeat rate too high causes a lot of events -Status: Open +Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: Linux PHP Version:5.3.8 -Assigned To: +Assigned To:fat Block user comment: N Private report: N Previous Comments: [2011-08-28 16:59:07] adrien at antipoul dot fr Description: Hi, It seems that FPM has a heartbeat each 130ms. This is really short, and make php-fpm the #1 event generator on my personal server, that also runs Apache, NGinx, dovecot, powerdns, NSD3 and unicorn. There might be a good reason for such a heartbeat, but there also might be a way to at least increase it to 5 or 10 seconds. I'll be glad to help and get rid of this, as soon as I understand what this heartbeat is helpful for. -- Edit this bug report at https://bugs.php.net/bug.php?id=55526&edit=1
Bug #55510 [Com]: $_FILES 'name' missing first character after upload.
Edit report at https://bugs.php.net/bug.php?id=55510&edit=1
ID: 55510
Comment by: aaron at gwmicro dot com
Reported by:aaron at gwmicro dot com
Summary:$_FILES 'name' missing first character after upload.
Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: Windows Server 2008 R2
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I started going back version by version from 5.3.8 to see where the problem
started, and it seems to have begun with 5.3.7, as 5.3.6 works correctly. Once
again, I'm just replacing PHP builds -- I'm not modifying any else. With 5.3.6,
I get back what I would expect:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
With 5.3.7 and 5.3.8, I get back the missing first letter:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "eadme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
With 5.4.beta1-dev, I'm back to getting everything that I expect:
array(1) { ["filename"]=> array(5) { ["name"]=> string(10) "readme.txt"
["type"]=> string(10) "text/plain" ["tmp_name"]=> string(31)
"C:\temp\file_upload\php594F.tmp" ["error"]=> int(0) ["size"]=> int(22) } }
Previous Comments:
[2011-08-28 17:21:37] aaron at gwmicro dot com
Here are the capture contents using Wireshark and PHP 5.3.8:
No. TimeSourceDestination Protocol Length
Info
1203 7.25209310.0.0.251184.18.147.3 HTTP 986
POST /private/aaron/filename.php HTTP/1.1 (text/plain)
Frame 1203: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb), Dst: 3com_49:bb:06
(00:01:02:49:bb:06)
Internet Protocol Version 4, Src: 10.0.0.251 (10.0.0.251), Dst: 184.18.147.3
(184.18.147.3)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80),
Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary:
"---9503744825200"
[Type: multipart/form-data]
First boundary: -9503744825200\r\n
Encapsulated multipart part: (text/plain)
Content-Disposition: form-data; name="filename";
filename="readme.txt"\r\n
Content-Type: text/plain\r\n\r\n
Line-based text data: text/plain
Hello! This is a test.
Last boundary: \r\n-9503744825200--\r\n
No. TimeSourceDestination Protocol Length
Info
1205 7.25278210.0.0.1 10.0.0.251HTTP 986
POST /private/aaron/filename.php HTTP/1.1 (text/plain)
Frame 1205: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits)
Ethernet II, Src: 3com_49:bb:06 (00:01:02:49:bb:06), Dst: AsustekC_8e:2f:bb
(00:26:18:8e:2f:bb)
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.251
(10.0.0.251)
Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80),
Seq: 1, Ack: 1, Len: 932
Hypertext Transfer Protocol
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary:
"---9503744825200"
[Type: multipart/form-data]
First boundary: -9503744825200\r\n
Encapsulated multipart part: (text/plain)
Content-Disposition: form-data; name="filename";
filename="readme.txt"\r\n
Content-Type: text/plain\r\n\r\n
Line-based text data: text/plain
Hello! This is a test.
Last boundary: \r\n-9503744825200--\r\n
[2011-08-26 23:02:34] johan...@php.net
Keeping state at "Feedback" until data requested by mafick is provided.
[2011-08-26 20:46:53] aaron at gwmicro dot com
Yes, I will attempt to get this information to you. I can say that we were
using 5.2.13 without incident prior to updating to 5.3.8. After updating to
5.3.8, we were notified by users that they could no longer download files that
they were successfully uploading. That was when I determined the missing first
character. Because we didn't want to go backward, I put on the 5.4 version, and
the problem went away. Note that no changes were made in the PHP source during
the process of changing versions. I will try to back all that with the
requested data.
[2011-08-26 19:02:04] v
Bug #55510 [Com]: $_FILES 'name' missing first character after upload.
Edit report at https://bugs.php.net/bug.php?id=55510&edit=1 ID: 55510 Comment by: aaron at gwmicro dot com Reported by:aaron at gwmicro dot com Summary:$_FILES 'name' missing first character after upload. Status: Feedback Type: Bug Package:Filesystem function related Operating System: Windows Server 2008 R2 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Here are the capture contents using Wireshark and PHP 5.3.8: No. TimeSourceDestination Protocol Length Info 1203 7.25209310.0.0.251184.18.147.3 HTTP 986 POST /private/aaron/filename.php HTTP/1.1 (text/plain) Frame 1203: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits) Ethernet II, Src: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb), Dst: 3com_49:bb:06 (00:01:02:49:bb:06) Internet Protocol Version 4, Src: 10.0.0.251 (10.0.0.251), Dst: 184.18.147.3 (184.18.147.3) Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80), Seq: 1, Ack: 1, Len: 932 Hypertext Transfer Protocol MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---9503744825200" [Type: multipart/form-data] First boundary: -9503744825200\r\n Encapsulated multipart part: (text/plain) Content-Disposition: form-data; name="filename"; filename="readme.txt"\r\n Content-Type: text/plain\r\n\r\n Line-based text data: text/plain Hello! This is a test. Last boundary: \r\n-9503744825200--\r\n No. TimeSourceDestination Protocol Length Info 1205 7.25278210.0.0.1 10.0.0.251HTTP 986 POST /private/aaron/filename.php HTTP/1.1 (text/plain) Frame 1205: 986 bytes on wire (7888 bits), 986 bytes captured (7888 bits) Ethernet II, Src: 3com_49:bb:06 (00:01:02:49:bb:06), Dst: AsustekC_8e:2f:bb (00:26:18:8e:2f:bb) Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.251 (10.0.0.251) Transmission Control Protocol, Src Port: 65260 (65260), Dst Port: http (80), Seq: 1, Ack: 1, Len: 932 Hypertext Transfer Protocol MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---9503744825200" [Type: multipart/form-data] First boundary: -9503744825200\r\n Encapsulated multipart part: (text/plain) Content-Disposition: form-data; name="filename"; filename="readme.txt"\r\n Content-Type: text/plain\r\n\r\n Line-based text data: text/plain Hello! This is a test. Last boundary: \r\n-9503744825200--\r\n Previous Comments: [2011-08-26 23:02:34] johan...@php.net Keeping state at "Feedback" until data requested by mafick is provided. [2011-08-26 20:46:53] aaron at gwmicro dot com Yes, I will attempt to get this information to you. I can say that we were using 5.2.13 without incident prior to updating to 5.3.8. After updating to 5.3.8, we were notified by users that they could no longer download files that they were successfully uploading. That was when I determined the missing first character. Because we didn't want to go backward, I put on the 5.4 version, and the problem went away. Note that no changes were made in the PHP source during the process of changing versions. I will try to back all that with the requested data. [2011-08-26 19:02:04] v-mafick at microsoft dot com I've setup Apache 2.2.19 and PHP 5.3.8 (though not with mod_ssl) and have run the test script you provided, but it doesn't produce the problem you reported (it works fine). In your report, $_FILES['filename']['name'] reports the length of the string as 10, even though only 9 characters are displayed. Is it possible that somewhere in your program you're converting between charsets or mangling the filename. Also, could you provide a packet capture of the network traffic between your web browser and your web application. You can do this with Wireshark (Windows/Linux) or NetMon (Windows). [2011-08-25 19:46:39] aaron at gwmicro dot com While I'm not enamored with the idea of running a beta in production, this problem appears to be resolved in 5.4.0beta1-dev. [2011-08-25 19:36:54] aaron at gwmicro dot com Description: After uploading a file using a multipart/form-data HTML form, the resulting file name is missing the initial character (i.e. rea
[PHP-BUG] Req #55526 [NEW]: Heartbeat rate too high causes a lot of events
From: Operating system: Linux PHP version: 5.3.8 Package: FPM related Bug Type: Feature/Change Request Bug description:Heartbeat rate too high causes a lot of events Description: Hi, It seems that FPM has a heartbeat each 130ms. This is really short, and make php-fpm the #1 event generator on my personal server, that also runs Apache, NGinx, dovecot, powerdns, NSD3 and unicorn. There might be a good reason for such a heartbeat, but there also might be a way to at least increase it to 5 or 10 seconds. I'll be glad to help and get rid of this, as soon as I understand what this heartbeat is helpful for. -- Edit bug report at https://bugs.php.net/bug.php?id=55526&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55526&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55526&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55526&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55526&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55526&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55526&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55526&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55526&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55526&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55526&r=support Expected behavior: https://bugs.php.net/fix.php?id=55526&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55526&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55526&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55526&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55526&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55526&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55526&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55526&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55526&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55526&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55526&r=mysqlcfg
Bug #55485 [Opn->Csd]: Compile ERROR: undefined symbol: xmlParserInputBufferCreateFilenameDefault
Edit report at https://bugs.php.net/bug.php?id=55485&edit=1 ID: 55485 User updated by:pedro dot galan at cscamaras dot es Reported by:pedro dot galan at cscamaras dot es Summary:Compile ERROR: undefined symbol: xmlParserInputBufferCreateFilenameDefault -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Red Hat Enterprise Linux Server PHP Version:5.3.7 Block user comment: N Private report: N New Comment: No need to keep open this possible bug report Previous Comments: [2011-08-28 15:32:29] pedro dot galan at cscamaras dot es Finally I was able to compiple php 5.3.7 on my system. There was an older version of libxml2 on the system, additional to that installed on /usr (version 2.6.26), and this older vesion had preference because it was listed before at /etc/ld.so.cache file. Setting the LD_LIBRARY_PATH with /usr/lib value before trying to compile php 5.3.7 solved this problem. Of course there could be another options to solve this issue. [2011-08-23 05:36:47] pedro dot galan at cscamaras dot es Description: ./configure '--prefix=/usr/local/php532' '--with-config-file-path=/usr/local/php532/lib' '--disable-debug' '--disable-rpath' ' --enable-inline-optimization' '--with-curl' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-iconv' '--with- pcre-regex' '--with-zlib' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enabl e-sysvsem' '--enable-sysvshm' '--enable-wddx' '--with-pear' '--with-kerberos' '--with-ldap' '--with-mysql' '--with-mysqli' '-- with-pgsql' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--enable-mbstring=shared' '--enable-mbregex' '--ena ble-pcntl' '--with-gd' '--with-jpeg-dir=/usr/lib' make Expected result: PHP gets compiled Actual result: -- ... Generating phar.php /usr/local/src/php-5.3.7/sapi/cli/php: symbol lookup error: /usr/local/src/php-5.3.7/sapi/cli/php: undefined symbol: xmlParserInputBufferCreateFilenameDefault make: *** [ext/phar/phar.php] Error 127 -- Edit this bug report at https://bugs.php.net/bug.php?id=55485&edit=1
Bug #55485 [Opn]: Compile ERROR: undefined symbol: xmlParserInputBufferCreateFilenameDefault
Edit report at https://bugs.php.net/bug.php?id=55485&edit=1 ID: 55485 User updated by:pedro dot galan at cscamaras dot es Reported by:pedro dot galan at cscamaras dot es Summary:Compile ERROR: undefined symbol: xmlParserInputBufferCreateFilenameDefault Status: Open Type: Bug Package:Compile Failure Operating System: Red Hat Enterprise Linux Server PHP Version:5.3.7 Block user comment: N Private report: N New Comment: Finally I was able to compiple php 5.3.7 on my system. There was an older version of libxml2 on the system, additional to that installed on /usr (version 2.6.26), and this older vesion had preference because it was listed before at /etc/ld.so.cache file. Setting the LD_LIBRARY_PATH with /usr/lib value before trying to compile php 5.3.7 solved this problem. Of course there could be another options to solve this issue. Previous Comments: [2011-08-23 05:36:47] pedro dot galan at cscamaras dot es Description: ./configure '--prefix=/usr/local/php532' '--with-config-file-path=/usr/local/php532/lib' '--disable-debug' '--disable-rpath' ' --enable-inline-optimization' '--with-curl' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-iconv' '--with- pcre-regex' '--with-zlib' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enabl e-sysvsem' '--enable-sysvshm' '--enable-wddx' '--with-pear' '--with-kerberos' '--with-ldap' '--with-mysql' '--with-mysqli' '-- with-pgsql' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--enable-mbstring=shared' '--enable-mbregex' '--ena ble-pcntl' '--with-gd' '--with-jpeg-dir=/usr/lib' make Expected result: PHP gets compiled Actual result: -- ... Generating phar.php /usr/local/src/php-5.3.7/sapi/cli/php: symbol lookup error: /usr/local/src/php-5.3.7/sapi/cli/php: undefined symbol: xmlParserInputBufferCreateFilenameDefault make: *** [ext/phar/phar.php] Error 127 -- Edit this bug report at https://bugs.php.net/bug.php?id=55485&edit=1
[PHP-BUG] Bug #55525 [NEW]: --enable-zend-multibyte cause Apache exit on signal 10
From: Operating system: FreeBSD 7.4 PHP version: 5.3.8 Package: Apache related Bug Type: Bug Bug description:--enable-zend-multibyte cause Apache exit on signal 10 Description: --enable-zend-multibyte in "configure" script (Zend Multibyte Support = Enabled) cause Apache's child processes outputs any result, but exit on signal 10 when in PHP-script there is syntax error and when MaxRequestPerChild != 1. Tested on Apache 1.3 and Apache 2.2 building PHP from FreeBSD ports or from source directly. Test script: --- Expected result: Work correctly on any next request Actual result: -- Apache's child proccess outputs any result (text of syntax error) and exit with signal 10. It cause fails at the next request (Apache server close connection without any result), when request is scheduled to the killed child. -- Edit bug report at https://bugs.php.net/bug.php?id=55525&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55525&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55525&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55525&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55525&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55525&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55525&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55525&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55525&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55525&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55525&r=support Expected behavior: https://bugs.php.net/fix.php?id=55525&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55525&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55525&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55525&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55525&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55525&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55525&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55525&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55525&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55525&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55525&r=mysqlcfg
Bug #30157 [Com]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Comment by: bugs dot php at mohiva dot com Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Open Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: >> Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. Previous Comments: [2011-08-26 13:26:58] bugs dot php at mohiva dot com Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). >> Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? [2011-08-25 12:30:42] bugs dot php at mohiva dot com Two years later the bug is still present in 5.3.8 [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. [2006-07-26 16:43:31] w...@php.net (PS: I got here via Bug #37096) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157&edit=1
Req #53436 [Fbk->Opn]: RFE: add check for php headers in phpize
Edit report at https://bugs.php.net/bug.php?id=53436&edit=1 ID: 53436 User updated by:fedora at famillecollet dot com Reported by:fedora at famillecollet dot com Summary:RFE: add check for php headers in phpize -Status: Feedback +Status: Open Type: Feature/Change Request Package:Compile Failure Operating System: GNU/Linux (Fedora 14) PHP Version:5.3SVN-2010-12-01 (SVN) Block user comment: N Private report: N New Comment: > This patch can not be incorporated as-is - it refers to "php-devel package", Yes, the message need to be more "generic" > In general, I'm not sure why PECL command should always fail on --version > if headers are not present, Because phpize get version from headers (see phpize_get_api_numbers) > so how this patch improves things? Giving a comprehensive explanation to the user (the reason why the build fails) Previous Comments: [2011-08-28 09:44:45] s...@php.net This patch can not be incorporated as-is - it refers to "php-devel package", which has no meaning outside of certain binary distributions of PHP. In general, I'm not sure why PECL command should always fail on --version if headers are not present, especially since, as you suggest, it may be useful without them. As for the build, if I understand correctly, the build would fail anyway if headers are not present, so how this patch improves things? [2010-12-01 15:49:52] fedora at famillecollet dot com Description: phpize is used to build pecl extension. This script already does a lot of sanity check before the build. On GNU/Linux distribution, PHP headers are available in a sub-package phpize should check if header are available before running the build. See : https://bugzilla.redhat.com/657812 Note than pecl command is usefull, even without "php-devel" to register/unregister packaged extension (--nobuild option), to list regitered extensions, etc. Test script: --- # yum remove php-devel # or any other command, apt, ... # pecl install APC Expected result: 49 source files, building running: phpize Can't find PHP headers in /usr/include/php The php-devel package is required for use of this command. ERROR: `phpize' failed -- Edit this bug report at https://bugs.php.net/bug.php?id=53436&edit=1
Req #53436 [Opn->Fbk]: RFE: add check for php headers in phpize
Edit report at https://bugs.php.net/bug.php?id=53436&edit=1 ID: 53436 Updated by: s...@php.net Reported by:fedora at famillecollet dot com Summary:RFE: add check for php headers in phpize -Status: Open +Status: Feedback Type: Feature/Change Request Package:Compile Failure Operating System: GNU/Linux (Fedora 14) PHP Version:5.3SVN-2010-12-01 (SVN) Block user comment: N Private report: N Previous Comments: [2011-08-28 09:44:45] s...@php.net This patch can not be incorporated as-is - it refers to "php-devel package", which has no meaning outside of certain binary distributions of PHP. In general, I'm not sure why PECL command should always fail on --version if headers are not present, especially since, as you suggest, it may be useful without them. As for the build, if I understand correctly, the build would fail anyway if headers are not present, so how this patch improves things? [2010-12-01 15:49:52] fedora at famillecollet dot com Description: phpize is used to build pecl extension. This script already does a lot of sanity check before the build. On GNU/Linux distribution, PHP headers are available in a sub-package phpize should check if header are available before running the build. See : https://bugzilla.redhat.com/657812 Note than pecl command is usefull, even without "php-devel" to register/unregister packaged extension (--nobuild option), to list regitered extensions, etc. Test script: --- # yum remove php-devel # or any other command, apt, ... # pecl install APC Expected result: 49 source files, building running: phpize Can't find PHP headers in /usr/include/php The php-devel package is required for use of this command. ERROR: `phpize' failed -- Edit this bug report at https://bugs.php.net/bug.php?id=53436&edit=1
Req #53436 [Opn]: RFE: add check for php headers in phpize
Edit report at https://bugs.php.net/bug.php?id=53436&edit=1 ID: 53436 Updated by: s...@php.net Reported by:fedora at famillecollet dot com Summary:RFE: add check for php headers in phpize Status: Open Type: Feature/Change Request Package:Compile Failure Operating System: GNU/Linux (Fedora 14) PHP Version:5.3SVN-2010-12-01 (SVN) Block user comment: N Private report: N New Comment: This patch can not be incorporated as-is - it refers to "php-devel package", which has no meaning outside of certain binary distributions of PHP. In general, I'm not sure why PECL command should always fail on --version if headers are not present, especially since, as you suggest, it may be useful without them. As for the build, if I understand correctly, the build would fail anyway if headers are not present, so how this patch improves things? Previous Comments: [2010-12-01 15:49:52] fedora at famillecollet dot com Description: phpize is used to build pecl extension. This script already does a lot of sanity check before the build. On GNU/Linux distribution, PHP headers are available in a sub-package phpize should check if header are available before running the build. See : https://bugzilla.redhat.com/657812 Note than pecl command is usefull, even without "php-devel" to register/unregister packaged extension (--nobuild option), to list regitered extensions, etc. Test script: --- # yum remove php-devel # or any other command, apt, ... # pecl install APC Expected result: 49 source files, building running: phpize Can't find PHP headers in /usr/include/php The php-devel package is required for use of this command. ERROR: `phpize' failed -- Edit this bug report at https://bugs.php.net/bug.php?id=53436&edit=1
Bug #30959 [Com]: __call does not return by reference
Edit report at https://bugs.php.net/bug.php?id=30959&edit=1
ID: 30959
Comment by: michael at unsolicted dot yahoo dot com
Reported by:joel at zmail dot pt
Summary:__call does not return by reference
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5CVS-2005-03-09
Assigned To:andi
Block user comment: N
Private report: N
New Comment:
With all due respect, "only variables should be assigned by reference" makes no
sense.
__call does not assign variables. It executes code for innaccessible methods,
and that code may wish to return a reference.
Not bogus; this functionality existed in PHP4 as __call()'s third parameter was
passed by reference.
Although this is in no way justification for the fix (as I have already
justified it) consider this: (pedantic error checking removed for simplicity)
{substr($method,3)};
}
function &__get($property)
{
return $this->{'get'.$property}();
}
}
$hello = new Hello;
$hello->world[] = 'php maintainers always say NO';
?>
--which does not work. For those of us mere 'users' who need this, as a work
around try this:
world;
}
}
?>
--which DOES work, although that is not really the point!
Previous Comments:
[2005-06-19 02:28:03] sni...@php.net
PHP Strict Standards: Only variables should be assigned by reference
[2005-03-09 01:00:30] sni...@php.net
Andi, is this the final call? :)
(documentation or engine change..that is the question)
[2005-03-08 12:53:29] joel at zmail dot pt
well, then that info about __call and return by reference should go into the
manual, in the __call section.
right?
[2005-03-08 12:50:23] he...@php.net
At the moment __call() relies on the internal signature which is return by copy
and the fact that the engine prevents from implementing return by reference
functions at c-level.
[2005-03-08 12:01:42] joel at zmail dot pt
I've just tested with latest php 5 (php5-200503080930)
and the problem is not solved.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=30959
--
Edit this bug report at https://bugs.php.net/bug.php?id=30959&edit=1
Bug #55524 [Opn->Asn]: Traits should not be able to extend a class
Edit report at https://bugs.php.net/bug.php?id=55524&edit=1
ID: 55524
Updated by: g...@php.net
Reported by:g...@php.net
Summary:Traits should not be able to extend a class
-Status: Open
+Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:5.4.0alpha3
-Assigned To:
+Assigned To:gron
Block user comment: N
Private report: N
Previous Comments:
[2011-08-28 08:05:04] g...@php.net
Description:
Spotted by this post: http://zuttonet.com/articles/php-class-traits/
Traits build their own hierarchy of uses, but there is no useful semantics for
extending classes.
For instance:
trait Foo extends Base {
function bar() {}
}
The semantics for that is not defined (and actually at least broken for
abstract
methods).
This should give a fatal error as would the other way around (Base extends Foo).
Test script:
---
trait Foo extends Base {
function bar() {}
}
Expected result:
Fatal error: A trait (Foo) cannot extend a class (Base) in %s on line %d
--
Edit this bug report at https://bugs.php.net/bug.php?id=55524&edit=1
[PHP-BUG] Bug #55524 [NEW]: Traits should not be able to extend a class
From: gron
Operating system:
PHP version: 5.4.0alpha3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Traits should not be able to extend a class
Description:
Spotted by this post: http://zuttonet.com/articles/php-class-traits/
Traits build their own hierarchy of uses, but there is no useful semantics
for
extending classes.
For instance:
trait Foo extends Base {
function bar() {}
}
The semantics for that is not defined (and actually at least broken for
abstract
methods).
This should give a fatal error as would the other way around (Base extends
Foo).
Test script:
---
trait Foo extends Base {
function bar() {}
}
Expected result:
Fatal error: A trait (Foo) cannot extend a class (Base) in %s on line %d
--
Edit bug report at https://bugs.php.net/bug.php?id=55524&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55524&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55524&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55524&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55524&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55524&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55524&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55524&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55524&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55524&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55524&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55524&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55524&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55524&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55524&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55524&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55524&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55524&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55524&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55524&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55524&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55524&r=mysqlcfg
Req #55523 [Opn->Bgs]: Make a real object oriented language
Edit report at https://bugs.php.net/bug.php?id=55523&edit=1 ID: 55523 Updated by: ka...@php.net Reported by:foo at bar dot baz Summary:Make a real object oriented language -Status: Open +Status: Bogus Type: Feature/Change Request Package:Unknown/Other Function Operating System: Any PHP Version:Irrelevant 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 Previous Comments: [2011-08-28 07:07:06] foo at bar dot baz Description: >From a technical point of view PHP is by far one of the worst programming languages I have ever come across. I don't have to point out the details since anyone with a good programming background should find this obvious. The designers either have no idea of what object oriented is all about, or are stuck with backward compatibility issues, or can not afford to loose money. PHP has been teaching very bad programming practices over the years. Stop all current versions. Redesign the language from scratch and stop making excuses such as "it works", "everyone is using it", etc. If you still think that PHP is fine, then please get another job. -- Edit this bug report at https://bugs.php.net/bug.php?id=55523&edit=1
[PHP-BUG] Req #55523 [NEW]: Make a real object oriented language
From: Operating system: Any PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:Make a real object oriented language Description: >From a technical point of view PHP is by far one of the worst programming languages I have ever come across. I don't have to point out the details since anyone with a good programming background should find this obvious. The designers either have no idea of what object oriented is all about, or are stuck with backward compatibility issues, or can not afford to loose money. PHP has been teaching very bad programming practices over the years. Stop all current versions. Redesign the language from scratch and stop making excuses such as "it works", "everyone is using it", etc. If you still think that PHP is fine, then please get another job. -- Edit bug report at https://bugs.php.net/bug.php?id=55523&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55523&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55523&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55523&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55523&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55523&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55523&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55523&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55523&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55523&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55523&r=support Expected behavior: https://bugs.php.net/fix.php?id=55523&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55523&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55523&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55523&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55523&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55523&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55523&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55523&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55523&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55523&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55523&r=mysqlcfg
