Re: [PHP-DEV] New escaped output operator

[Михаил Востриков]

> If you're answer for the other contexts is to use a template engine,
> why is the answer for this not to use a template engine?
> You want to add this because people don't use template engine,
> so what makes you think they will use this when there is a valid solution
already available?

Because it is almost impossible to add template engine in a big project
with PHP templates. But new version of language usually can easily be used.

Because this is very frequent operation, and error or inattention with
current syntax can cause security problems.

Because other filters are task-dependent, not external-context-dependent.
Of course, we can have own file format with PHP processing for our tasks,
and external context won't be HTML, but then it is task-dependent context.
Actually, HTML is also task-dependent external context, and PHP was made
(and is used) specially for this task.

And because for other context you may need a filter combination, so single
operator will not be very useful.
But last filter in a chain is our external context, and external context in
very many cases is HTML/XML.


2016-07-01 1:42 GMT+05:00 Ryan Pallas :

>
>
> On Thu, Jun 30, 2016 at 1:35 PM, Михаил Востриков <
> michael.vostri...@gmail.com> wrote:
>
>>
>>
>> - Other people will ask about operator for another context
>> And you can say: We already added an operator for the main web context,
>> because it is the most frequently used context. If you have a lot of work
>> with other contexts, please use template engine.
>>
>>
> If you're answer for the other contexts is to use a template engine, why
> is the answer for this not to use a template engine? You want to add this
> because people don't use template engine, so what makes you think they will
> use this when there is a valid solution already available?
>

Re: [PHP-DEV] [RFC] Iterable

[Nikita Popov]

On Thu, Jun 30, 2016 at 10:01 PM, Jeremy Mikola  wrote:

> On Sat, Jun 18, 2016 at 11:34 AM, Aaron Piotrowski 
> wrote:
>
> >
> > I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable)
> > to a vote in about a week, does anyone have any further feedback on this
> > proposal?
> >
>
> Was there any discussion about a special allowance being made for stdClass?
>
> I've noted the is_iterable(new stdClass) example and ensuing "Object
> Iteration" section:
>
> PHP allows any object to be used with foreach. However, iterable does not
> > accept any object, only those implementing Traversable. Values accepted
> > by iterable should be designed for iteration, not any set of values (such
> > as the public properties of an object or a string).
> >
>
> I'm on the fence if that second sentence applies to stdClass. Based on how
> users typically end up with stdClass instances (e.g. casting arrays to an
> object, json_decode()), I tend to think of them as logically equivalent to
> associative arrays. To that end, I'd consider stdClass to be as "designed
> for iteration" as any associative array -- if we can even say a stdClass
> was designed at all :)
>
> As-is, the RFC requires users to either cast stdClass instances to an array
> or decorate them with an Iterator (e.g. ArrayObject). I find this a bit
> irksome, but it's certainly easy to work around.
>
> That said, I realize that voting is in progress and it's not my intention
> to interrupt anything. I just wanted to relay a viewpoint that might not
> have come up.
>
> --
> jeremy mikola
>

Instead of adding a special case to iterable, we could also make stdClass
implement Traversable. (If we agree that stdClass is explicitly intended
for iteration -- not so sure on that.)

Nikita

Re: [PHP-DEV] New escaped output operator

[Thomas Bley]

> What for?

 is easy to verify

 is not easy to verify

Regards

Rasmus Schultz wrote on 30.06.2016 22:27:

> I wish you'd think about the bigger issue of autoloading functions,
> which would solve this and many similar problems much more generally.
> 
> I mean, this:
> 
> 
> 
> versus this:
> 
> 
> 
> What for?
> 
> I don't see the point in inventing new syntax, and introducing a new
> concept, for what is effectively just a limited set of certain
> specific functions.
> 
> We have functions already - rather than adding new features, we should
> improve the features we already have instead, which benefits the
> language as a whole, not just templates. Improving on functions is
> long over due...
> 
> 
> On Thu, Jun 30, 2016 at 9:52 PM, Thomas Bley  wrote:
>> I would prefer to have ENT_HTML5 as the default flag included, since normally
>> all new html code is html5.
>> Maybe split voting between > >
>> Regards
>> Thomas
>>
>> Михаил Востриков wrote on 30.06.2016 21:35:
>>
>>> I've tried to gather all arguments for and against.
>>>
>>> To be clear. I suggest new operator like '' which is
>>> equivalent of .
>>> It is only for HTML context. Flag combination is taken from most popular
>>> frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of
>>> operator and default flags are the details of implementation.
>>>
>>>
>>>
>>> - You can write short function in userland.
>>>
>>> The problem is not that we have no function. The problem is that the same
>>> action is always repeated, and if we don't repeat it then it leads to
>>> security problems. More than 90% of output data - is data from DB and must
>>> be HTML-encoded.
>>>
>>> There is no such problem with other contexts. If we don't call json_encode
>>> when passing an array or object into javascript, this only breaks the
>>> script, and it will be noticeable, there won't be security problems.
>>>
>>> With new operator we can write or , or , they are mutually
>>> exclusive, and we need specially write one or another, but with helper
>>> function we have the same beginning >> or not.
>>>
>>> Also there is a problem with function autoloading.
>>>
>>>
>>>
>>> - It is no place for such operators in the language.
>>> It is no place for a such operators in C++, or C#, or Java. But in the most
>>> popular language for web-programming it is very place for such operator.
>>>
>>>
>>>
>>> - There are many other contexts
>>>
>>> HTML is external context, but others are internal task-dependent contexts.
>>> HTML can be used together with other contexts.
>>> HTML context is the main context in every PHP file, and we write >> the beginning to switch it.
>>>
>>> Actually, on web page we have 3 external contexts - HTML, script> tag,
>>> 

Re: [PHP-DEV] [RFC][Vote] ReflectionType Improvements

[Nikita Popov]

On Thu, Jun 30, 2016 at 6:06 PM, Levi Morrison  wrote:

> The RFC for improving ReflectionType[1] is now in voting phase. The voting
> window is June 30th through July 8th. I have not finished the patch but
> I'll have it done before the end of voting.
>
>   [1]: https://wiki.php.net/rfc/ReflectionTypeImprovements


Replying on-list as multiple people asked:

I'm voting against this RFC, because it introduced not only the
ReflectionNamedType class (which is reasonable), but also the
ReflectionClassType class (which is not).

My main objection to ReflectionClassType is that it is autoloading
dependent (*). Something like getReturnType() on a class type hint will
either return a ReflectionClassType if the class can be loaded, or a
ReflectionNamedType if it can't. I think this is confusing and I'm sure
that this will lead to broken code: For example, people will try to use
"$type instanceof ReflectionClassType" to check whether something is a
class type hint, while the currently correct way, which works independently
of class loading, is to check isBuiltin() instead.

I don't think that most consumers of ReflectionType are interested in
obtaining a ReflectionClass for the type hint anyway (which is the only
functionality that ReflectionClassType provides), and if necessary this can
be easily done in userland. There is no need to over-complicate the
ReflectionType functionality in this manner, especially with the proposed
semantics.

Nikita

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Aaron Piotrowski]

Hi Chris,

> On Jun 30, 2016, at 6:15 AM, Christopher Jones  
> wrote:
> 
> Hi Aaron,
> 
> I was someone who spent time on the RFC template to try and get better
> quality and to capture more information about each RFC.  I think your
> RFC needs a lot more content before going to the vote.
> 
> Chris
> 

It was unclear if these changes even needed a formal RFC, but the RMs felt it 
would be better to have an RFC to ensure extension maintainers and others were 
aware of and agreed with the changes to be made. The RFC was short because I 
felt there wasn't much to say. However, I have added to the RFC a list of 
extensions and under what conditions an instance of Error will be thrown 
instead of a fatal or recoverable fatal error. Hopefully this is along the 
lines of what you were looking for.

If possible, I would still like each extension maintainer to take a look at the 
changes made to ensure I have not missed cleaning up cases where bail-out 
behavior was being relied upon.

Cheers!

Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New escaped output operator

[Ryan Pallas]

On Thu, Jun 30, 2016 at 1:35 PM, Михаил Востриков <
michael.vostri...@gmail.com> wrote:

>
>
> - Other people will ask about operator for another context
> And you can say: We already added an operator for the main web context,
> because it is the most frequently used context. If you have a lot of work
> with other contexts, please use template engine.
>
>
If you're answer for the other contexts is to use a template engine, why is
the answer for this not to use a template engine? You want to add this
because people don't use template engine, so what makes you think they will
use this when there is a valid solution already available?

Re: [PHP-DEV] New escaped output operator

[Rasmus Schultz]

I wish you'd think about the bigger issue of autoloading functions,
which would solve this and many similar problems much more generally.

I mean, this:



versus this:



What for?

I don't see the point in inventing new syntax, and introducing a new
concept, for what is effectively just a limited set of certain
specific functions.

We have functions already - rather than adding new features, we should
improve the features we already have instead, which benefits the
language as a whole, not just templates. Improving on functions is
long over due...


On Thu, Jun 30, 2016 at 9:52 PM, Thomas Bley  wrote:
> I would prefer to have ENT_HTML5 as the default flag included, since normally 
> all new html code is html5.
> Maybe split voting between  
> Regards
> Thomas
>
> Михаил Востриков wrote on 30.06.2016 21:35:
>
>> I've tried to gather all arguments for and against.
>>
>> To be clear. I suggest new operator like '' which is
>> equivalent of .
>> It is only for HTML context. Flag combination is taken from most popular
>> frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of
>> operator and default flags are the details of implementation.
>>
>>
>>
>> - You can write short function in userland.
>>
>> The problem is not that we have no function. The problem is that the same
>> action is always repeated, and if we don't repeat it then it leads to
>> security problems. More than 90% of output data - is data from DB and must
>> be HTML-encoded.
>>
>> There is no such problem with other contexts. If we don't call json_encode
>> when passing an array or object into javascript, this only breaks the
>> script, and it will be noticeable, there won't be security problems.
>>
>> With new operator we can write or , or , they are mutually
>> exclusive, and we need specially write one or another, but with helper
>> function we have the same beginning > or not.
>>
>> Also there is a problem with function autoloading.
>>
>>
>>
>> - It is no place for such operators in the language.
>> It is no place for a such operators in C++, or C#, or Java. But in the most
>> popular language for web-programming it is very place for such operator.
>>
>>
>>
>> - There are many other contexts
>>
>> HTML is external context, but others are internal task-dependent contexts.
>> HTML can be used together with other contexts.
>> HTML context is the main context in every PHP file, and we write > the beginning to switch it.
>>
>> Actually, on web page we have 3 external contexts - HTML, script> tag,
>> 

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Dan Ackroyd]

On 30 June 2016 at 01:32, Pierre Joye  wrote:
>> It's not a language change, so doesn't seem to meet the criteria for
>> needing a 2/3 pass rate.
>
> It is changing the core like ext/standard and other core functions.

That's true, but doesn't appear to be the required test. From the Voting RFC:

> a feature affecting the language itself (new syntax for example) will be 
> considered as 'accepted'
> if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 
> 'accepted'.

Although the core functions ship as PHP they aren't part of the
language, so 50% + 1 seems to appropriate.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Iterable

[Jeremy Mikola]

On Sat, Jun 18, 2016 at 11:34 AM, Aaron Piotrowski 
wrote:

>
> I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable)
> to a vote in about a week, does anyone have any further feedback on this
> proposal?
>

Was there any discussion about a special allowance being made for stdClass?

I've noted the is_iterable(new stdClass) example and ensuing "Object
Iteration" section:

PHP allows any object to be used with foreach. However, iterable does not
> accept any object, only those implementing Traversable. Values accepted
> by iterable should be designed for iteration, not any set of values (such
> as the public properties of an object or a string).
>

I'm on the fence if that second sentence applies to stdClass. Based on how
users typically end up with stdClass instances (e.g. casting arrays to an
object, json_decode()), I tend to think of them as logically equivalent to
associative arrays. To that end, I'd consider stdClass to be as "designed
for iteration" as any associative array -- if we can even say a stdClass
was designed at all :)

As-is, the RFC requires users to either cast stdClass instances to an array
or decorate them with an Iterator (e.g. ArrayObject). I find this a bit
irksome, but it's certainly easy to work around.

That said, I realize that voting is in progress and it's not my intention
to interrupt anything. I just wanted to relay a viewpoint that might not
have come up.

-- 
jeremy mikola

Re: [PHP-DEV] New escaped output operator

[Thomas Bley]

I would prefer to have ENT_HTML5 as the default flag included, since normally 
all new html code is html5.
Maybe split voting between  I've tried to gather all arguments for and against.
> 
> To be clear. I suggest new operator like '' which is
> equivalent of .
> It is only for HTML context. Flag combination is taken from most popular
> frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of
> operator and default flags are the details of implementation.
> 
> 
> 
> - You can write short function in userland.
> 
> The problem is not that we have no function. The problem is that the same
> action is always repeated, and if we don't repeat it then it leads to
> security problems. More than 90% of output data - is data from DB and must
> be HTML-encoded.
> 
> There is no such problem with other contexts. If we don't call json_encode
> when passing an array or object into javascript, this only breaks the
> script, and it will be noticeable, there won't be security problems.
> 
> With new operator we can write or , or , they are mutually
> exclusive, and we need specially write one or another, but with helper
> function we have the same beginning  or not.
> 
> Also there is a problem with function autoloading.
> 
> 
> 
> - It is no place for such operators in the language.
> It is no place for a such operators in C++, or C#, or Java. But in the most
> popular language for web-programming it is very place for such operator.
> 
> 
> 
> - There are many other contexts
> 
> HTML is external context, but others are internal task-dependent contexts.
> HTML can be used together with other contexts.
> HTML context is the main context in every PHP file, and we write  the beginning to switch it.
> 
> Actually, on web page we have 3 external contexts - HTML, script> tag,
> 

Re: [PHP-DEV] New escaped output operator

[Михаил Востриков]

I've tried to gather all arguments for and against.

To be clear. I suggest new operator like '' which is
equivalent of .
It is only for HTML context. Flag combination is taken from most popular
frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of
operator and default flags are the details of implementation.



- You can write short function in userland.

The problem is not that we have no function. The problem is that the same
action is always repeated, and if we don't repeat it then it leads to
security problems. More than 90% of output data - is data from DB and must
be HTML-encoded.

There is no such problem with other contexts. If we don't call json_encode
when passing an array or object into javascript, this only breaks the
script, and it will be noticeable, there won't be security problems.

With new operator we can write or , or , they are mutually
exclusive, and we need specially write one or another, but with helper
function we have the same beginning  tag,

[PHP-DEV] Request: Prevention of FPD in Fatal/Parse/Other Errors

[Ted Phillips]

Hi,

 

Currently the only real "solution" to Full Path Disclosure vulnerabilities in 
software developed in PHP is to keep display_errors disabled. Even if a 
developer wishes to prevent disclosures at the application level instead, it is 
not currently possible with the current implementation of PHP:

 

- The output text of Parse and Fatal Errors cannot be modified, far as I can 
tell

- Some errors can be triggered by specially crafted requests and occur before 
the application initializes (think max_input_vars, and other input-related 
errors)

- Custom error handlers are needed to remove path strings for other errors, but 
if multiple frameworks are used together, the error handlers may conflict on 
which strings should be removed. Only 1 shutdown function can actually be used.

 

I propose that the default error handling in PHP be updated as follows:

 

- Include a new ini directive for fpd_prevention, defaulting to On or a string 
for replacement, like the ever-popular [path]

- Provide a new function hide_fpd_path (or pick a better name), defined as:

function hide_fpd_path($path, $replacement_string = '')

$replacement_string would default to the system defined [path] string or other 
ini value. The function provides an interface to a registry of paths that 
should not appear in error output, should an error occur.

- Automatically treat the paths in include_path (and updated by 
set_include_path) as if they were registered with hide_fpd_path, using the 
default replacement string or other [include-path] string. Because of 
set_include_path's existence, it may be best to apply this at error time.

- Automatically register the containing path of PHP_SELF at initialization. 
This will deal will fatal errors occurring before the application can specify 
its paths, such as when max_input_vars is exceeded by a crafted request.

- When outputting any error, including E_ERROR or E_PARSE, filter the file 
paths with this new registry, applying the most specific pathnames first. Now 
the security implications of display_errors are largely mitigated.

- Many custom error handlers use debug_backtrace or debug_print_backtrace. I 
would suggest adding a new DEBUG_BACKTRACE_SKIP_FPD constant in case the error 
handler absolutely does not want the paths filtered by PHP. However, because 
there are cases where multiple frameworks have error handlers with different 
internal filters, I believe the default behavior of debug_backtrace should 
pre-filter those. This way, developers of other modules and plugins can still 
add filters, regardless of whatever framework is on top.

 

By resolving full path disclosures at the scripting engine level, or at least 
providing a built-in solution for them (which per my suggestion could be 
disabled if system administrators don't want to use it), PHP can help change 
the conversation on full path disclosures:

 

Many instances of full-path disclosure vulnerabilities currently go unresolved 
because there is a debate whether they are configuration issues (of 
display_errors) vs bugs in the application, because some developers are 
resistant to writing software that works well in tandem with the software of 
other developers, and because many developers do not want to release security 
patches every time a fatal error is found, especially when it is still possible 
to cause fatal errors that the application has no control over. The question is 
sometimes raised whether FPD issues are really worthy of being considered 
security issues at all; however, I have seen authorities issue CVEs for them. I 
think this suggestion provides a solution for all these camps of people.

 

Thanks,

Ted

[PHP-DEV] [RFC][Vote] ReflectionType Improvements

[Levi Morrison]

The RFC for improving ReflectionType[1] is now in voting phase. The voting
window is June 30th through July 8th. I have not finished the patch but
I'll have it done before the end of voting.

  [1]: https://wiki.php.net/rfc/ReflectionTypeImprovements

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-06-30

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-30 06:30:36+03:00
commit: e247e93
previous commit:0a4f89b
revision date:  2016-06-29 20:51:10+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.17% -0.32%  0.23%  
  7.77%
:-|   Drupal 7.36 cgi -T1  0.26% -0.46% -0.62%  
  5.18%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07% -0.03%  1.27%  
  3.87%
:-|   bench.php cgi -T100  0.01%  0.17% 27.02%  
  1.05%
:-|  micro_bench.php cgi -T10  0.00% -0.93%  4.46%  
  3.42%
:-(  mandelbrot.php cgi -T100  0.04% -1.52% 30.54%  
  3.40%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-06-30/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PDO_pgsql and "?" json operator (was [PHP-DEV] About PHP 7.1.0 Feature Freeze)

[Matteo Beccati]

Hi Davey,

I'm patching in internals again, as I should probably have done in the
first place ;)

On 30/06/2016 13:04, Davey Shafik wrote:
>> On Thu, Jun 30, 2016 at 3:56 AM, Matteo Beccati > > wrote:
>> 
>> Hi Davey, Joe,
>> 
>> I'm sending this email to check with you if you think it's appropriate
>> for me to go ahead and merge the following to master:
>> 
>> https://github.com/php/php-src/pull/1967
>> 
>> It's basically something in between a feature and a bug fix for:
>> 
>> https://bugs.php.net/71885
>> 
>> i.e. allowing pdo_pgsql users to escape question mark placeholders in
>> order to use the json "?" operator (and others, also containing a "?").
> 
> 
> I think that given there are potentially other possibilities for solving
> this issue, I'd like to see an RFC.
> 
> Personally, I'd prefer to see PDO have feature flags to support the $#
> syntax that is used natively, and ignore all question marks. Or perhaps
> allow switching to '$?' (which should be possible to distinguish from
> the operator). Or allow turning off anonymous placeholders, and only use
> named placeholders.
> 
> I wouldn't want to get any further away from _actual_ pgsql syntax than
> we have to, and I think this current patch does that.
> 
> Thoughts?

Supporting Postgres' own placeholders would mean moving away from PDO's
own syntax and it would seem quite odd to me. Not to mention something
painful to support in the various database libraries.

On the other hand a system to enable/disable placeholder types seems
fairly easy to implement and possibly cleaner, but it would be rather
awkward to use and very cumbersome, if feasible at all, for those not
using PDO directly.

That said, I'll be happy to put forward an RFC if necessary, but that
would be probably a few months from now and targeting 7.2.

While I'm at it... would would be the proper workflow for asking to
become maintainer for pdo_pgsql?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Christopher Jones]

On 28/06/2016 1:17 AM, Aaron Piotrowski wrote:

Hello,

Voting has opened on the RFC to change most conditions in extensions that raise 
E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead.

RFC: https://wiki.php.net/rfc/throw_error_in_extensions 

PR: https://github.com/php/php-src/pull/1942 


Aaron Piotrowski



Hi Aaron,

I was someone who spent time on the RFC template to try and get better
quality and to capture more information about each RFC.  I think your
RFC needs a lot more content before going to the vote.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] RNG fixes

[Leigh]

Updated RFC

* Removed proposal to replace (mt_)rand with an alternative algorithm
as many have expressed concerns with this.
* Clarified that the output of mt_rand _appears_ to be high quality as-is
* Added that the old mt_rand functionality will be available at
runtime via `mt_rand_mode()`

I'll have an implementation ready for review by the end of the week.

On 16 June 2016 at 19:54, Leigh  wrote:
> RFC updated to include:
> * A note about mt_rand()s poor performance
> * Separate votes for proposals so we can at least get the security fixes
> through
> * Updated vote from 50% to 2/3 as it does cause a BC issue.
>
> I should also state that mt_rand is easily implementable in userland, so the
> correct/legacy algorithm can be provided that way if changing it in core
> does not pass (I have a library providing this)
>
> So there have been a couple of suggestions of providing legacy functionality
> via a PECL extension. If we were to make rand/mt_rand use function pointers
> to their implementation it would be very easy for an extension to override
> their behaviour. If people like this idea I'm more than happy to provide
> this ext as part of the RFC.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php