Req #62783 [Com]: Request of using methods for core types.
Edit report at https://bugs.php.net/bug.php?id=62783edit=1
ID: 62783
Comment by: hinikato at mail dot ru
Reported by:hinikato at mail dot ru
Summary:Request of using methods for core types.
Status: Open
Type: Feature/Change Request
Package:Class/Object related
PHP Version:5.4.6RC1
Block user comment: N
Private report: N
New Comment:
One more important addition: I suggest to introduce camelCased() methods
because we have PSR-2 standard and SPL.
Previous Comments:
[2012-08-09 04:10:19] hinikato at mail dot ru
@larue...@php.net, thank you for this info, I really don't know about such use
case of self with combination of the __call() method. However I talk about
native implementation that has difference with described wrapper:
1. Performance - native implementation should be more fast because it will be
written on C (not PHP).
2. The native implementation is more short and it is more ease to use. The
developer don't need to do something like that:
?php
foreach ($arrayOfString as $string) {
$string = new Strings($string);
}
unset($string);
?
to add string's methods for all items of array. It is obviously that such
conversions is inconvenient and make our code not so beautiful.
3. Native methods will support exceptions. This mean that old checking like:
if ($result == false) {
throw new Exception();
}
will not be required. This will let us write less code and do more.
4. We will have set of standard methods - as result PHP developers will not
develop new wrappers (bicycles) to resolve basic tasks.
5. Native methods will be supported for all strings, arrays etc, it will lead
that user will be able to pass any of existing (native) method as callback.
6. It will allow to fix old inconsistent with parameters, so we will not have
something like this:
array array_diff_ukey ( array $array1 , array $array2 [, array $ ... ],
callable $key_compare_func )
array array_map ( callable $callback , array $arr1 [, array $... ] )
bool array_walk_recursive ( array $input , callable $funcname [, mixed
$userdata = NULL ] )
Why the callback is on 1, 2 and third place here??? It is so inconvenient. It
is hard to remember and use. I and all my PHP friends need to use PHP docs
almost every time when we use any of such functions! Please fix it too ;)
7. It is more object oriented way. PHP will be more beautiful and more
logically structured.
8. (optional) User will be able to extend native classes to add missing methods
(like Ruby, JavaScript allows to do).
--
All developers that I know including me would like to have such features in PHP
;)
[2012-08-09 03:35:23] larue...@php.net
you can already do it with a wrapper of string now:
?php
class Strings {
private $str = NULL;
function __construct($str) {
$this-str = $str;
}
function __call($method, $params) {
return new self($method($this-str));
}
function __toString() {
return $this-str;
}
}
echo (new Strings(Hello, World))-strtolower()-ucfirst();
[2012-08-09 00:50:39] hinikato at mail dot ru
Removed the non-relevant field for the issue description.
[2012-08-09 00:38:00] hinikato at mail dot ru
Description:
I propose to introduce new methods for the core PHP types like arrays, strings,
floats etc? For example it would be super cool to write something like this:
[1, 2, 3]-sort()
Hello, World-lowercase()-ucfirst() etc.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62783edit=1
Bug #40459 [ReO-Csd]: Stat and Dir stream wrapper methods do not call constructor
Edit report at https://bugs.php.net/bug.php?id=40459edit=1
ID: 40459
Updated by: s...@php.net
Reported by:clay at killersoft dot com
Summary:Stat and Dir stream wrapper methods do not call
constructor
-Status: Re-Opened
+Status: Closed
Type: Bug
Package:Streams related
Operating System: irrelevant
PHP Version:5.2.1
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-08-09 07:12:26] s...@php.net
Automatic comment on behalf of stas
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=4db70fd406c805a296f4531088fe716a1ef67158
Log: fix bug #40459 - make all stream funcs that create object call ctor
[2012-08-07 23:48:41] s...@php.net
See also: https://github.com/php/php-src/pull/93
[2012-05-04 12:47:27] jschipp...@php.net
I believe this issue is still present. I have attached a test case to
demonstrate the problem.
When looking at main/streams/userspace.c, it is clear that only in
user_wrapper_opener() the constructor of the user space class is called (the
if (uwrap-ce-constructor) {} block).
[2012-05-04 12:46:05] jschipp...@php.net
The following patch has been added/updated:
Patch Name: bug-40459
Revision: 1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459patch=bug-40459revision=1336135565
[2008-07-21 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
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=40459
--
Edit this bug report at https://bugs.php.net/bug.php?id=40459edit=1
[PHP-BUG] Bug #62784 [NEW]: DateTime: last day of with timestamps is buggy
From: daniel dot rudolf at eifel-online dot com
Operating system: Windows XP
PHP version: 5.3.15
Package: Date/time related
Bug Type: Bug
Bug description:DateTime: last day of with timestamps is buggy
Description:
Using new DateTime(last day of @timestamp) doesn't work properly
Test script:
---
?php
$time = new DateTime('2012-01-01 00:00:00 UTC');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('now'); // today = 2012-08-09
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('2020-12-12');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('2000-02-01'); // leapyear
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('2000-02-01 00:00:01 UTC');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
?
Expected result:
2012-01-01 -- 2012-01-31
2012-08-09 -- 2012-08-31
2020-12-12 -- 2020-12-31
2000-02-01 -- 2000-02-29
2000-02-01 -- 2000-02-29
Actual result:
--
2012-01-01 -- 2012-01-31
2012-08-09 -- 2012-09-08
2020-12-12 -- 2021-01-10
2000-02-01 -- 2000-03-01
2000-02-01 -- 2000-03-02
--
Edit bug report at https://bugs.php.net/bug.php?id=62784edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62784r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62784r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62784r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62784r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62784r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62784r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62784r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62784r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62784r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62784r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62784r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62784r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62784r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62784r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62784r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62784r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62784r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62784r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62784r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62784r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62784r=mysqlcfg
Bug #62784 [Com]: DateTime: last day of with timestamps is buggy
Edit report at https://bugs.php.net/bug.php?id=62784edit=1
ID: 62784
Comment by: daniel dot rudolf at eifel-online dot com
Reported by:daniel dot rudolf at eifel-online dot com
Summary:DateTime: last day of with timestamps is buggy
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows XP
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
Note that only timestamps are affected!
?php
$time = new DateTime('2000-02-01 00:00:01 UTC');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of '.date('r', $time));
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
// Expected and actual result: 2000-02-01 -- 2000-02-29
?
Previous Comments:
[2012-08-09 07:58:46] daniel dot rudolf at eifel-online dot com
Description:
Using new DateTime(last day of @timestamp) doesn't work properly
Test script:
---
?php
$time = new DateTime('2012-01-01 00:00:00 UTC');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('now'); // today = 2012-08-09
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('2020-12-12');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('2000-02-01'); // leapyear
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
/* --- */
$time = new DateTime('2000-02-01 00:00:01 UTC');
$time = $time-getTimestamp();
$monthEnd = new DateTime('last day of @'.$time);
echo date('Y-m-d', $time). -- .$monthEnd-format('Y-m-d').\n;
?
Expected result:
2012-01-01 -- 2012-01-31
2012-08-09 -- 2012-08-31
2020-12-12 -- 2020-12-31
2000-02-01 -- 2000-02-29
2000-02-01 -- 2000-02-29
Actual result:
--
2012-01-01 -- 2012-01-31
2012-08-09 -- 2012-09-08
2020-12-12 -- 2021-01-10
2000-02-01 -- 2000-03-01
2000-02-01 -- 2000-03-02
--
Edit this bug report at https://bugs.php.net/bug.php?id=62784edit=1
Bug #47789 [Com]: Opera file upload - multiple files from one input cannot be handled
Edit report at https://bugs.php.net/bug.php?id=47789edit=1 ID: 47789 Comment by: carlosbacco at gmail dot com Reported by:michal dot aichinger at gmail dot com Summary:Opera file upload - multiple files from one input cannot be handled Status: Not a bug Type: Bug Package:*General Issues Operating System: Windows / Linux PHP Version:5.2.9 Block user comment: N Private report: N New Comment: Why devs seem to be ignoring this ugly and olg bug? Do PHP devs have something against Opera? Previous Comments: [2011-04-03 21:30:59] sergei dot fukurokudzu at gmail dot com Hi there. It's realy php bug. can you solve it finaly please?! [2010-12-01 04:45:16] ahar...@php.net This is also covered by request #50338 -- which is still open. I'll add a note to it that this affects more than just Web Forms 2.0. [2010-11-30 21:10:11] imbolk at gmail dot com Hello! It is not bogus! Look at RFC2388! [2010-06-21 17:59:12] imbolk at gmail dot com Hey! What about this bug? It's not bogus! RFC2388 www.ietf.org/rfc/rfc2388.txt Returning Values from Forms: multipart/form-data, L. Masinter. IETF, August 1998. 4.2 Sets of files If the value of a form field is a set of files rather than a single file, that value can be transferred together using the «multipart/mixed» format. [2010-06-19 18:34:23] sowingsadness at gmail dot com http://tools.ietf.org/html/rfc1867 3.3 use of multipart/form-data The definition of multipart/form-data is included in section 7. A boundary is selected that does not occur in any of the data. (This selection is sometimes done probabilisticly.) Each field of the form is sent, in the order in which it occurs in the form, as a part of the multipart stream. Each part identifies the INPUT name within the original HTML form. Each part should be labelled with an appropriate content-type if the media type is known (e.g., inferred from the file extension or operating system typing information) or as application/octet-stream. If multiple files are selected, they should be transferred together using the multipart/mixed format. 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=47789 -- Edit this bug report at https://bugs.php.net/bug.php?id=47789edit=1
Bug #62785 [Opn]: mktime() and strtotime() does not return anything for date '2050-12-31''
Edit report at https://bugs.php.net/bug.php?id=62785edit=1
ID: 62785
Updated by: paj...@php.net
Reported by:d dot sandip59 at gmail dot com
Summary:mktime() and strtotime() does not return anything
for date '2050-12-31''
Status: Open
Type: Bug
-Package:date_time
+Package:Date/time related
Operating System: Windows XP
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
fix category
Previous Comments:
[2012-08-09 12:13:27] anon at anon dot anon
https://en.wikipedia.org/wiki/Year_2038_problem
[2012-08-09 10:00:42] d dot sandip59 at gmail dot com
Description:
I have use this date:-
$exp_date = 2050-12-31 00:00:00;
$timestamp = strtotime($exp_date);
echo $timestamp;
But i got no timestamp value for it.
Also, I am using this following code:-
list($year, $month, $date) = explode('-', $exp_date);
$timestamp = mktime(0,0,0, $month,$date,$year);
echo $timestamp;
But i also got no timestamp value for it.
Test script:
---
I have use this date:-
$exp_date = 2050-12-31 00:00:00;
$timestamp = strtotime($exp_date);
echo $timestamp;
list($year, $month, $date) = explode('-', $exp_date);
$timestamp = mktime(0,0,0, $month,$date,$year);
echo $timestamp;
Expected result:
It show return a timestamp value even after the year 2037. Till the year 2037
it is returning valid timestamp value, but after that it does not return any
timestamp value.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62785edit=1
Req #49513 [Com]: SoapServer-fault() shouldn't halt execution
Edit report at https://bugs.php.net/bug.php?id=49513edit=1
ID: 49513
Comment by: jeroen at asystance dot nl
Reported by:amr dot mostafa at gmail dot com
Summary:SoapServer-fault() shouldn't halt execution
Status: Open
Type: Feature/Change Request
Package:SOAP related
Operating System: GNU/Linux
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
This behavior is very undesirable!
How can I let a client know about the fault _and_ do server-side Exception
handling?
I'd love to do
try {
$server-handle();
} catch (Exception $e) {
$server-fault($e-getCode(), $e-getMessage());
throw $e;
}
To have default handling for uncaught Exceptions (which logs to file, email,
whatever), but that's not possible.
Previous Comments:
[2009-09-09 12:54:09] amr dot mostafa at gmail dot com
Description:
Calling SoapServer-fault() causes execution to terminate, there is no way for
the developer to get the XML response itself and process it differently.
Reproduce code:
---
$server = SoapServer(NULL, array('location' = 'http://example.com', 'uri' =
'http://example.com'));
$server-fault('foo', 'bar');
echo 'We are past $sever-fault()!'
Expected result:
We are past $server-fault()!
Actual result:
--
We are past $server-fault()! is never printed, only the XML for the SOAP
Fault is.
--
Edit this bug report at https://bugs.php.net/bug.php?id=49513edit=1
Bug #27792 [Com]: [PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir)
Edit report at https://bugs.php.net/bug.php?id=27792edit=1 ID: 27792 Comment by: adu at rdsor dot ro Reported by:kode at kodekrash dot com Summary:[PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir) Status: Critical Type: Bug Package:Filesystem function related Operating System: * (LFS) PHP Version:5.*, 6CVS (2009-04-30) Block user comment: N Private report: N New Comment: @marcb I tested it in PHP 5.4.0 (cli) (built: Apr 12 2012 13:02:59)) on Ubuntu 12.04 kernel 3.0.0-19 i686 and the BUG is still here. Reproduced code: $fname = 'file_of_7GB'; var_dump(filesize( $fname )); // PHP Warning: filesize(): stat failed for file_of_7GB in php_bug_27792.php on line 4 // dumps bool(false) var_dump(is_file( $fname )); // dumps bool(false) var_dump(is_dir( $fname )); // dumps bool(false) $fname = 'file_of_354MB'; var_dump(filesize( $fname )); // dumps int(370336155) var_dump(is_file( $fname )); // dumps bool(true) var_dump(is_dir( $fname )); // dumps bool(false) Previous Comments: [2011-01-05 04:46:23] marcb at voicemeup dot com Is anyone able to confirm if this was fixed in any of the 5.X branch ? This is a pretty stupid problem to have to deal with ! [2009-11-12 10:27:45] boite dot pour dot spam at gmail dot com The patch from Wez doesn't work, as it assumes size_t are 64 bits, which is not the case, even when LFS is defined. The patch from Mail Pourri works on 5.3.0 (I haven't tested in 5.3.1) [2009-09-14 08:59:36] j...@php.net The latest patch for this: http://www.php.net/~wez/lfs.diff [2009-07-11 13:40:57] mail dot pourri at laposte dot net Please see fix in http://bugs.php.net/bug.php?id=48886 [2009-04-30 19:45:57] j...@php.net And bug #45040 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=27792 -- Edit this bug report at https://bugs.php.net/bug.php?id=27792edit=1
Bug #53934 [Com]: The negative PHP_INT_MAX is incorrectly converted to float
Edit report at https://bugs.php.net/bug.php?id=53934edit=1
ID: 53934
Comment by: ajf at ajf dot me
Reported by:eriksen dot costa at infranology dot com dot br
Summary:The negative PHP_INT_MAX is incorrectly converted to
float
Status: Verified
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
@catphract:
In that case is it not a tokeniser issue, and -9223372036854775807 should be
tokenised to '-9223372036854775807' not '-' '9223372036854775807'?
Previous Comments:
[2011-02-05 18:55:33] cataphr...@php.net
The problem is that -9223372036854775808 is not parsed as an integer, instead
the minus sign and the rest are parsed individually and 9223372036854775808 is
bigger than LONG_MAX.
Probably this is not trivial to fix.
[2011-02-05 14:53:32] eriksen dot costa at infranology dot com dot br
Description:
I found this and seems a bug. Everytime I use the negative PHP_INT_MAX
literally (-9223372036854775808) as a function parameter, it is converted to
float.
However, if I pass it like an expression -9223372036854775807 - 1, it is
correctly identified as an integer.
Test script:
---
--TEST--
Checks if the negative PHP_INT_MAX is treated as integer.
--CREDITS--
Eriksen Costa eriksen.co...@infranology.com.br
--SKIPIF--
?php
if (PHP_INT_SIZE 8) die('64bit platforms only');
?
--FILE--
?php
var_dump(-9223372036854775807 - 1);
var_dump((PHP_INT_MAX * -1) - 1);
var_dump(-9223372036854775808);
?
--EXPECT--
int(-9223372036854775808);
int(-9223372036854775808);
int(-9223372036854775808);
Expected result:
int(-9223372036854775808);
int(-9223372036854775808);
int(-9223372036854775808);
Actual result:
--
int(-9223372036854775808)
int(-9223372036854775808)
float(-9.2233720368548E+18)
--
Edit this bug report at https://bugs.php.net/bug.php?id=53934edit=1
[PHP-BUG] Req #62787 [NEW]: Named function parameters
From: bouanto at gmail dot com
Operating system: all
PHP version: 5.4.6RC1
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:Named function parameters
Description:
Hello!
I know this feature request has been made a few times in the last years,
but I
want to reopen this request to add arguments in favor to this feature
request.
It would be really nice for developper to be able to call a function like
this:
func($param1 = 'value1', $param2 = 'value2');
or a similar way.
The func function would be defined that way:
function func(...$options) {}
or another syntax.
This way, we've got not problem with documentation if we compare to the
array-
way.
The goal of this syntax is to simplify the function call and get shorter
code.
Not convinced?
Let's compare two web framework: one in a language that support named
function
parameters and one that doesn't.
Drupal (PHP) and Django (Python).
Drupal uses the array-way as you recommend.
Here is the way Drupal allows us to create a database table model:
http://api.drupal.org/api/drupal/modules%21system%21system.api.php/function/hook_schema/7
(go down to the code section)
And look at the named-parameter-way in Django in the Test script.
The code is almost five times shorter in python, because of the use of
named
parameters.
It is the primary reason to include this syntax in PHP:
we can get shorter and cleaner code.
Thanks for considering this feature request once again.
And I hope you will do the right choice now.
I am open to argumentation.
Test script:
---
Python code almost equivalent to the Drupal code:
from datetime import datetime
from django.db import models
class Node(models.Model):
vid = models.PositiveIntegerField(default=0, null=False, unique=True)
changed = models.DateTimeField(default=datetime.now, db_index=True,
null=False)
created = models.DateTimeField(default=datetime.now, db_index=True,
null=False)
type = models.CharField(default='', max_length=32, null=False)
title = models.CharField(default='', max_length=255, null=False)
revision = models.ForeignKey('NodeRevision')
author = models.ForeignKey('User')
--
Edit bug report at https://bugs.php.net/bug.php?id=62787edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62787r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62787r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62787r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62787r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62787r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62787r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62787r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62787r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62787r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62787r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62787r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62787r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62787r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62787r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62787r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62787r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62787r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62787r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62787r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62787r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62787r=mysqlcfg
Bug #61139 [ReO-Csd]: gzopen leaks when specifying invalid mode
Edit report at https://bugs.php.net/bug.php?id=61139edit=1 ID: 61139 Updated by: ni...@php.net Reported by:ni...@php.net Summary:gzopen leaks when specifying invalid mode -Status: Re-Opened +Status: Closed Type: Bug Package:Zlib related PHP Version:Irrelevant Assigned To:nikic Block user comment: N Private report: N New Comment: The invalid move occurs within zlib, so this is rather a 3rd party issue. The only thing we could do here is manually check whether the mode is valid. Previous Comments: [2012-07-29 06:17:03] larue...@php.net valgrind complains : ==21723== Conditional jump or move depends on uninitialised value(s) ==21723==at 0x3055402F6A: ??? (in /usr/lib64/libz.so.1.2.3) ==21723==by 0x30554040A0: ??? (in /usr/lib64/libz.so.1.2.3) ==21723==by 0x3055404184: gzdopen (in /usr/lib64/libz.so.1.2.3) ==21723==by 0x572A0D: php_stream_gzopen (zlib_fopen_wrapper.c:137) ==21723==by 0x5711C7: zif_gzopen (zlib.c:592) ==21723==by 0x9A424E: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:642) ==21723==by 0x9ADB2B: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2219) ==21723==by 0x9A1E43: execute (zend_vm_execute.h:410) ==21723==by 0x95C1A9: zend_execute_scripts (zend.c:1289) ==21723==by 0x89AAF3: php_execute_script (main.c:2473) ==21723==by 0xAE4268: do_cli (php_cli.c:988) ==21723==by 0xAE5700: main (php_cli.c:1364) ==21723== [2012-07-24 23:37:18] ras...@php.net Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=ecd13fd184ab46136d893338748fcda6c1458c7f Log: Fix bug #61139 gzopen leaks when specifying invalid mode [2012-04-18 09:46:07] larue...@php.net Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=ecd13fd184ab46136d893338748fcda6c1458c7f Log: Fix bug #61139 gzopen leaks when specifying invalid mode [2012-03-02 14:16:40] ni...@php.net Automatic comment from SVN on behalf of nikic Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=323819 Log: Merge: Fix bug #61139: gzopen leaks when specifying invalid mode [2012-02-19 14:41:21] ni...@php.net Keeping open til merged to 5.4. 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=61139 -- Edit this bug report at https://bugs.php.net/bug.php?id=61139edit=1
Bug #44337 [Com]: PDO::FETCH_CLASS and visibility private (private constructor, private property)
Edit report at https://bugs.php.net/bug.php?id=44337edit=1
ID: 44337
Comment by: Stephen dot Reay at me dot com
Reported by:uwendel at mysql dot com
Summary:PDO::FETCH_CLASS and visibility private (private
constructor, private property)
Status: No Feedback
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.2CVS-2008-03-05 (CVS)
Block user comment: N
Private report: N
New Comment:
This bug still exists in PHP 5.3 - what extra information is required for this
to
be fixed?
Previous Comments:
[2009-05-03 01:00:11] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-04-25 14:56:12] j...@php.net
Why is this here? You should discuss stuff on the mailing lists, nobody
seems to read the bug reports (who actually know the stuff..).
[2008-03-05 15:29:34] uwendel at mysql dot com
Description:
Please clearify if any of the following is a bug or a feature.
1) PDO::FETCH_CLASS and private constructor
PDO ignores the visibility private of a constructor and creates objects of
the requested type when using PDO::FETCH_CLASS and PDOStatement-fetch().
Create a class with a private constructor and try to create an object of the
class from somewhere outside of the class. PHP will print a fatal error as
expected.
class private_constructor {
private function __construct()
}
$obj = new private_constructor() -- Fatal error (OK)
Use PDOStatement-setFetchMode() to make PDO return objects of the type
private_constructor when fetching results. setFetchMode() will return true
and PDOStatement-fetch() will return objects of the type
private_constructor. In other words: PDO will ignore the visibility of the
constructor and behave as if PDO would be a part of the class
private_constructor
2) PDO::FETCH_CLASS and private properties
Something similar happens if you make PDO instantiate a class with private
properties which have the same name as column in the result set. PDO does not
bother about private and fills the appropriate properties with values from the
result set.
Reproduce code:
---
1 - private constructor -
php -r '$db = new PDO(sqlite:/tmp/foo); $db-exec(DROP TABLE test);
$db-exec(CREATE TABLE test (id INT)); $db-exec(INSERT INTO test(id) VALUES
(1)); $stmt = $db-prepare(SELECT id FROM test); class private_constructor {
public static $calls = 0; private function __construct() {
printf(private_constructor: %d\n, self::$calls++); }}
$stmt-setFetchMode(PDO::FETCH_CLASS, 'private_constructor'); $stmt-execute();
var_dump($stmt-fetch());'
private_constructor: 0
object(private_constructor)#3 (1) {
[id]=
string(1) 1
}
- 2 - private properties ---
php -r '$db = new PDO(sqlite:/tmp/foo); $db-exec(DROP TABLE test);
$db-exec(CREATE TABLE test (id INT)); $db-exec(INSERT INTO test(id) VALUES
(1)); $stmt = $db-prepare(SELECT id FROM test); class private_properties {
public static $calls = 0; private $id; public function __construct() {
printf(private_properties: %d\n, self::$calls++); }}
var_dump($stmt-setFetchMode(PDO::FETCH_CLASS, 'private_properties'));
$stmt-execute(); var_dump($stmt-fetch());'
bool(true)
private_properties: 0
object(private_properties)#3 (1) {
[id:private_properties:private]=
string(1) 1
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=44337edit=1
[PHP-BUG] Bug #62789 [NEW]: Autoloaders are invoked with invalid class names
From: drak at zikula dot org Operating system: PHP version: 5.3.15 Package: SPL related Bug Type: Bug Bug description:Autoloaders are invoked with invalid class names Description: It is possible to invoke class autoloaders with invalid class names leading to potential security issues. Classes can contain alphaumeric, underscore and backslash characters. However, code like: $foo = new $class where $class might contain any arbitrary string will cause the autoloader stack to be called even if the $class variable contained invalid characters for a class name. This could lead to various file inclusion issues as detailed in http://drak3.devmx.de/blog/2012/08/08/autoloaded-remote-file-inclusion/ However, it is not reasonable for classloaders to validate the class name passed to it via PHP for valid classname characters. Doing so would be an incredible burden on performance ever increasing with the size of the autoloader stack. I suggest that PHP validate the characters of the class before deciding to call the autoloader stack or not. -- Edit bug report at https://bugs.php.net/bug.php?id=62789edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62789r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62789r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62789r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62789r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62789r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62789r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62789r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62789r=needscript Try newer version: https://bugs.php.net/fix.php?id=62789r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62789r=support Expected behavior: https://bugs.php.net/fix.php?id=62789r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62789r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62789r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62789r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62789r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62789r=dst IIS Stability: https://bugs.php.net/fix.php?id=62789r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62789r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62789r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62789r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62789r=mysqlcfg
