Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

>> utf8_decode() and utf8_encode() are not needed and causing problems >> than solving. >> >> https://wiki.php.net/rfc/remove_utf_8_decode_encode ... > I think it would be the best we document deprecation and leave as it is now. > > I'll start vote tomorrow. If you have comment, please do so asap.

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 7:12 GMT+02:00 Yasuo Ohgaki : > Hi all, > > We all know, uniqid() is not unique at all and not safe as random ID > at all. This would be one of the most misused function because of its > name. > > https://github.com/php/php-src/blob/master/ext/standard/uniqid.c#L44 > > Bug report for th

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

On Fri, Sep 9, 2016 at 4:29 PM, Kazuo Oishi wrote: >>> utf8_decode() and utf8_encode() are not needed and causing problems >>> than solving. >>> >>> https://wiki.php.net/rfc/remove_utf_8_decode_encode > ... >> I think it would be the best we document deprecation and leave as it is now. >> >> I'll

Re: [PHP-DEV] [RFC] Make uniqid() more unique

Hi Niklas, On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: > 2016-09-09 7:12 GMT+02:00 Yasuo Ohgaki : >> >> Hi all, >> >> We all know, uniqid() is not unique at all and not safe as random ID >> at all. This would be one of the most misused function because of its >> name. >> >> https://githu

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: > I think it's better to leave it as is and deprecate and discourage its use. > There's already a big warning there. Dunno whether there are really valid > use cases for it. uniqid() is handy, when developer would like to sort something by "tim

[PHP-DEV] Re: Disabling mail header injections via extra(additional) headers.

Hi all, On Mon, Aug 8, 2016 at 8:33 AM, Yasuo Ohgaki wrote: > disabled \r\n injections, that could override hole contents of mail, > by checking string extra headers for mail/mb_send_mail already. > > Extra mail headers could be checked more by having array extra headers. > > https://bugs.php.net

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

2016-09-09 7:21 GMT+02:00 Yasuo Ohgaki : > Hi all, > > On Mon, Aug 15, 2016 at 12:17 PM, Yasuo Ohgaki wrote: > > utf8_decode() and utf8_encode() are not needed and causing problems > > than solving. > > > > https://wiki.php.net/rfc/remove_utf_8_decode_encode > > > > Proposal > > - Document depr

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi Niklas, On Fri, Sep 9, 2016 at 5:26 PM, Niklas Keller wrote: >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > Do you plan to emit E_DEPRECATED or only deprecate them via documentation? > > What about the alias suggestio

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Sent: Thursday, September 08, 2016 9:15 AM >To: Tony Marston >Cc: PHP Internals >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > >On Thu, Sep 8, 2016 at 9:43 AM, Tony Marston wrote: > >"Ferenc Kovacs" wrote in message >news:cah-pch568tpsztkwt553qvqy7jsp1tcqt5w

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki : > On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: > > I think it's better to leave it as is and deprecate and discourage its > use. > > There's already a big warning there. Dunno whether there are really valid > > use cases for it. > > uniqid() is ha

[PHP-DEV] Modern practices ...

Having slept on the discussion about people today expecting users each to have their own environment, I came to the something of an impasse. How many Linux installations run a package manager that allows individual users to install their own versions of Apache/PHP/Database/Git/Hg and so on. The who

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Sent: Thursday, September 08, 2016 1:44 PM >To: Tony Marston >Cc: PHP internals >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > >On Sep 8, 2016 3:05 PM, "Tony Marston" wrote: >> >> "Pierre Joye" wrote in message >> news:caezptu4twuap1xjx+z_n+sgj1ujptyn8pj5xuvmj

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On 09/09/16 06:12, Yasuo Ohgaki wrote: > I would like to > - Enable more entropy parameter on by default > - Add 256 bits random value (64 chars by HEX) from >php_random_bytes() instead of 1 char from php_combined_lcg() > > If all of us think "just fix it", then I'll just fix this in master

Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module

Hi Yasuo, > On 9 Sep 2016, at 06:12, Yasuo Ohgaki wrote: > > On Thu, Sep 8, 2016 at 9:13 PM, Stephen Reay wrote: >>> On 8 Sep 2016, at 17:49, Yasuo Ohgaki wrote: >>> >>> Hi Stephen, >>> >>> On Thu, Sep 8, 2016 at 7:34 PM, Stephen Reay >>> wrote: Adding a bunch of new functions is IMO

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Sent: Friday, September 09, 2016 12:55 AM >To: Tony Marston ; internals@lists.php.net >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle >Hi! > >> There should be a rule that nothing can be deprecated unless there is a >> viable, stable, fully functioning and fully sup

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

2016. szept. 9. 10:44 ezt írta ("Tony Marston" ): > > Sent: Thursday, September 08, 2016 9:35 AM > >To: Tony Marston > >Cc: PHP Internals > >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > > > > >On Thu, Sep 8, 2016 at 9:49 AM, Tony Marston wrote: > > > >"Michae

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On 09/09/2016 11:01, Tony Marston wrote: Sent: Friday, September 09, 2016 12:55 AM To: Tony Marston ; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle Hi! There should be a rule that nothing can be deprecated unless there is a viable, st

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

2016-09-09 10:31 GMT+02:00 Yasuo Ohgaki : > Hi Niklas, > > On Fri, Sep 9, 2016 at 5:26 PM, Niklas Keller wrote: >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> Do you plan to emit E_DEPRECATED or only deprecate them

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On Fri, Sep 9, 2016 at 7:12 AM, Yasuo Ohgaki wrote: > Hi all, > > We all know, uniqid() is not unique at all and not safe as random ID > at all. This would be one of the most misused function because of its > name. > > https://github.com/php/php-src/blob/master/ext/standard/uniqid.c#L44 > > Bug r

Re: [PHP-DEV] Modern practices ...

2016-09-09 10:39 GMT+02:00 Lester Caine : > Having slept on the discussion about people today expecting users each > to have their own environment, I came to the something of an impasse. > How many Linux installations run a package manager that allows > individual users to install their own versio

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 10:36 GMT+02:00 Arvids Godjuks : > 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki : > >> On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: >> > I think it's better to leave it as is and deprecate and discourage its >> use. >> > There's already a big warning there. Dunno whether there are r

Re: [PHP-DEV] Modern practices ...

On 9 September 2016 09:39:07 BST, Lester Caine wrote: >Back to PEAR ... what happens if I simply install a copy of composer >centrally and rename it 'PEAR'. composer.phar simply gets installed >centrally and any new tech has access without having to install their >own copy. This is more or less

Re: [PHP-DEV] Modern practices ...

On Fri, Sep 9, 2016 at 10:39 AM, Lester Caine wrote: > Having slept on the discussion about people today expecting users each > to have their own environment, I came to the something of an impasse. > How many Linux installations run a package manager that allows > individual users to install thei

Re: [PHP-DEV] Modern practices ...

On 09/09/16 11:30, Niklas Keller wrote: >> Back to PEAR ... what happens if I simply install a copy of composer >> > centrally and rename it 'PEAR'. > > Why rename it to PEAR? It's a different tool. Just call it Composer as it's > named. My point was just that as has already been established. com

[PHP-DEV] Re: [RFC] Make uniqid() more unique

Hi all, On Fri, Sep 9, 2016 at 2:12 PM, Yasuo Ohgaki wrote: > We all know, uniqid() is not unique at all and not safe as random ID > at all. This would be one of the most misused function because of its > name. > > https://github.com/php/php-src/blob/master/ext/standard/uniqid.c#L44 > > Bug repor

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 13:37 GMT+03:00 Niklas Keller : > 2016-09-09 10:36 GMT+02:00 Arvids Godjuks : > >> 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki : >> >>> On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: >>> > I think it's better to leave it as is and deprecate and discourage its >>> use. >>> > There's a

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi Kalle and all, On Fri, Sep 9, 2016 at 6:32 PM, Kalle Sommer Nielsen wrote: > 2016-09-09 10:31 GMT+02:00 Yasuo Ohgaki : >> Hi Niklas, >> >> On Fri, Sep 9, 2016 at 5:26 PM, Niklas Keller wrote: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://

Re: [PHP-DEV] Modern practices ...

On 09/09/16 11:55, Ferenc Kovacs wrote: >> Most sites will skip whole major versions of updates simply >> becuase their production system IS working ... > > usually it is easier to migrate in multiple smaller steps, but of course > there are people who will do the one big upgrade. Many of the si

Re: [PHP-DEV] Modern practices ...

On Fri, Sep 9, 2016 at 1:00 PM, Lester Caine wrote: > On 09/09/16 11:30, Niklas Keller wrote: > >> Back to PEAR ... what happens if I simply install a copy of composer > >> > centrally and rename it 'PEAR'. > > > > Why rename it to PEAR? It's a different tool. Just call it Composer as > it's > >

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle

On Thu, 8 Sep 2016, Davey Shafik wrote: > Anyway, this is far off topic IMO. This RFC isn't going to kill PEAR > (any deader than it already is :P) it will simply unbundle it from > core. If you want to continue using it, then by all means do so. And > ignore the potential fact that composer/pi

Re: [PHP-DEV] Modern practices ...

On 09/09/16 12:35, Ferenc Kovacs wrote: > but please, this is really offtopic on this list. See my other reply ... and composer global mode as provided out of the box is NOT an alternative to installing the sort of production and development - command line - tools that PEAR currently manages happi

Re: [PHP-DEV] [RFC] Make uniqid() more unique

Hi all, On Fri, Sep 9, 2016 at 8:18 PM, Arvids Godjuks wrote: > > Hm, without "true" you get 13 chars, with "true" - 20+. Sorry. It's $ php -r 'var_dump(uniqid(), uniqid("", true));' string(13) "57d29c20c04c3" string(23) "57d29c20c04c50.55225401" I misread sprintf format. Anyway, we may use e

[PHP-DEV] [PHPDEV] Bearer Auth

Came across this issue https://bugs.php.net/bug.php?id=72915 and got an idea. I've added PHP_AUTH_BEARER to $_SERVER when Bearer auth token is used as Authorization method. Does this kind of change requires RFC ? Would this kind of change be usefull enough to go into the codebase ? Here are the c

Re: [PHP-DEV] Modern practices ...

On Fri, Sep 9, 2016 at 1:45 PM, Lester Caine wrote: > On 09/09/16 12:35, Ferenc Kovacs wrote: > > but please, this is really offtopic on this list. > > See my other reply ... > and composer global mode as provided out of the box is NOT an > alternative to installing the sort of production and dev

Re: [PHP-DEV] [PHPDEV] Bearer Auth

2016-09-09 14:17 GMT+02:00 Silvio Marijić : > Came across this issue https://bugs.php.net/bug.php?id=72915 and got an > idea. I've added PHP_AUTH_BEARER to $_SERVER when Bearer auth token is used > as Authorization method. > > Does this kind of change requires RFC ? Would this kind of change be >

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 13:18 GMT+02:00 Arvids Godjuks : > > > 2016-09-09 13:37 GMT+03:00 Niklas Keller : > >> 2016-09-09 10:36 GMT+02:00 Arvids Godjuks : >> >>> 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki : >>> On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller wrote: > I think it's better to leave it as is

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 13:48 GMT+02:00 Yasuo Ohgaki : > Hi all, > > On Fri, Sep 9, 2016 at 8:18 PM, Arvids Godjuks > wrote: > > > > Hm, without "true" you get 13 chars, with "true" - 20+. > > Sorry. It's > > $ php -r 'var_dump(uniqid(), uniqid("", true));' > string(13) "57d29c20c04c3" > string(23) "57d29c20c

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On 9/9/16 4:36 AM, Arvids Godjuks wrote: It's also useful in other cases, where using a full blown true random source is just overkill. Users should not hesitate to use random_bytes() or php_random_bytes() or any of the functions that use them. For example, my recent usage was to use the

Re: [PHP-DEV] [RFC] Make uniqid() more unique

2016-09-09 15:46 GMT+03:00 Niklas Keller : > 2016-09-09 13:18 GMT+02:00 Arvids Godjuks : > >> >> >> 2016-09-09 13:37 GMT+03:00 Niklas Keller : >> >>> 2016-09-09 10:36 GMT+02:00 Arvids Godjuks : >>> 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki : > On Fri, Sep 9, 2016 at 4:40 PM, Niklas Kel

Re: [PHP-DEV] Modern practices ...

Hello, For myself I have adopted the "vagrant vm per project" workflow. I never mix projects, because while some are "primitive" and do not require anything beyond a standard install, others have a custom provisioning and setup stuff. And specific options on the software that can interfere with o

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On 9/9/16 7:18 AM, Arvids Godjuks wrote: 2016-09-09 13:37 GMT+03:00 Niklas Keller : Most people think getting true random is a overkill and implement things non-secure. Most? Idk. But there certainly are many programmers that still believe the **myth** that one should be conservative of the

Re: [PHP-DEV] Modern practices ...

On 09/09/16 13:32, Ferenc Kovacs wrote: > On Fri, Sep 9, 2016 at 1:45 PM, Lester Caine wrote: > >> > On 09/09/16 12:35, Ferenc Kovacs wrote: >>> > > but please, this is really offtopic on this list. >> > >> > See my other reply ... >> > and composer global mode as provided out of the box is NOT a

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On 9/9/16 7:48 AM, Yasuo Ohgaki wrote: Some of us feel returning almost random value from uniqid() is overkill. This is reasonable. How would it be overkill if uniqid() used, say, php_random_bytes()? Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://w

Re: [PHP-DEV] [RFC] Make uniqid() more unique

On 9/9/16 6:12 AM, Nikita Popov wrote: The problem with "fixing" this function to be cryptographically unpredictable (rather than just unique, for a limited definition of unique) is that it will necessarily change the size of the output, on which there may be assumptions. A 128 bit random value

[PHP-DEV] Re: [RFC] Make uniqid() more unique

On 09.09.2016 at 07:12, Yasuo Ohgaki wrote: > We all know, uniqid() is not unique at all and not safe as random ID > at all. This would be one of the most misused function because of its > name. uniqid() yields truly unique values for a single machine (except for CYGWIN, and potentially older Win

Re: [PHP-DEV] [PHPDEV] Bearer Auth

@Niklas We are already supporting Basic and Digest and Bearer and MAC are used widely as a form of token authorization. 2016-09-09 14:37 GMT+02:00 Niklas Keller : > 2016-09-09 14:17 GMT+02:00 Silvio Marijić : > >> Came across this issue https://bugs.php.net/bug.php?id=72915 and got an >> idea. I'

[PHP-DEV] Re: VCS Account Request: adambaratz

VCS Account Approved: adambaratz approved by tyrael \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: VCS Account Request: adambaratz

On Fri, Sep 9, 2016 at 5:12 PM, PHP Group wrote: > VCS Account Approved: adambaratz approved by tyrael \o/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > hi, I've approved your account, I will grant you appropriate karma

Re: [PHP-DEV] [PHPDEV] Bearer Auth

Does this change also leave the raw header in $_SERVER['HTTP_AUTHORIZATION’] ? > On 9 Sep 2016, at 21:30, Silvio Marijić wrote: > > @Niklas > We are already supporting Basic and Digest and Bearer and MAC are used > widely as a form of token authorization. > > 2016-09-09 14:37 GMT+02:00 Niklas K

Re: [PHP-DEV] [PHPDEV] Bearer Auth

@Stephen Yes, this change does not remove any previously variables in $_SERVER, only adds PHP_AUTH_BEARER when present in request. 2016-09-09 18:07 GMT+02:00 Stephen Reay : > Does this change also leave the raw header in > $_SERVER['HTTP_AUTHORIZATION’] ? > > > On 9 Sep 2016, at 21:30, Silvio Ma

[PHP-DEV] Re: [PDO] Shared behavior of persistent connections

Hi Matteo! Thanks for responding. :-) I'm forwarding to internals as per Kalle's suggestion. Cheers! On 09.09.2016 at 08:23, Matteo Beccati wrote: > I try to stay away as much as possible from persistent connections as > they can cause more issues than what they actually solve. I think I even

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-09-09

Results for project PHP master, build date 2016-09-09 06:25:31+03:00 commit: fd5f0e4 previous commit:8cce817 revision date: 2016-09-08 20:04:10+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] [PHPDEV] Bearer Auth

It does, This is sort of workaround. Authorization header is considered "custom" header and as such Apache strips it by default in order to enhance security. Unlike Apache, CGI and FP SAPI's allow this header. 2016-09-09 20:49 GMT+02:00 Stephen Reay : > Doesn't the bug specifically say that the e

Re: [PHP-DEV] RFC - Immutable classes

I see Reflection is still todo; should there be a similar escape hatch to ReflectionMethod::setAccessible()? This would allow things like: https://gist.github.com/fredemmott/01ad55c0c03c8d7ba62bbd6e9fb23686 (apologies for t

Re: [PHP-DEV] RFC - Immutable classes

@Fred Thanks for taking interest. I still need to fully patch reflection extension for this. We had more important discussions in the past two weeks. Cheers, Silvio 2016-09-09 21:46 GMT+02:00 Fred Emmott : > I see Reflection is still todo; should there be a similar escape hatch to > Reflection

Re: [PHP-DEV] RFC - Immutable classes

It will be patched before this RFC goes into official discussion. 2016-09-09 22:01 GMT+02:00 Silvio Marijić : > @Fred > > Thanks for taking interest. I still need to fully patch reflection > extension for this. We had more important discussions in the past two weeks. > > Cheers, > Silvio > > 2016

[PHP-DEV] Re: [RFC] Make uniqid() more unique

Hi Christoph, On Fri, Sep 9, 2016 at 10:56 PM, Christoph M. Becker wrote: >> We all know, uniqid() is not unique at all and not safe as random ID >> at all. This would be one of the most misused function because of its >> name. > > uniqid() yields truly unique values for a single machine (except

Re: [PHP-DEV] RFC - Immutable classes

On 9/9/2016 10:02 PM, Silvio Marijić wrote: > It will be patched before this RFC goes into official discussion. > That explains why all the rewritten tests I provided for Reflection fail: https://github.com/brzuchal/php-src/pull/1 Should I create this PR against another repository? I created it

Re: [PHP-DEV] RFC - Immutable classes

@Fleshgrinder, Well since implementation is still underway I think the best ways would be to wait untill we finish implementation, and then we all can do the review to make sure everything is in place. 2016-09-09 23:16 GMT+02:00 Fleshgrinder : > On 9/9/2016 10:02 PM, Silvio Marijić wrote: > > It

[PHP-DEV] Re: [RFC] Make uniqid() more unique

Hi all, On Sat, Sep 10, 2016 at 5:49 AM, Yasuo Ohgaki wrote: > On Fri, Sep 9, 2016 at 10:56 PM, Christoph M. Becker > wrote: >>> We all know, uniqid() is not unique at all and not safe as random ID >>> at all. This would be one of the most misused function because of its >>> name. >> >> uniqid(

[PHP-DEV] Re: The death of `#ifndef FAST_ZPP`?

Hi Cristoph, Christoph M. Becker wrote: In any case, thanks to some uncaught bugs in dead code, no stable release of PHP 7 has been able to compile with FAST_ZPP disabled anyway, which means I can be certain nobody is using it. I have successfully compiled a recent master with FAST_ZPP undefin

[PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

Hi all, As noted last week, I'm now opening up the vote for adding a PHP Engine Identifier constant to PHP 7.2+ (and more importantly, to the language spec). Additionally, there is a second vote to add corresponding PHP_ENGINE_(*_)VERSION(_ID) constants. https://wiki.php.net/rfc/php_engine_consta

[PHP-DEV] Re: The death of `#ifndef FAST_ZPP`?

Hi Andrea! On 10.09.2016 at 01:33, Andrea Faulds wrote: > Christoph M. Becker wrote: > >>> In any case, thanks to some uncaught bugs in dead code, no stable >>> release of PHP 7 has been able to compile with FAST_ZPP disabled anyway, >>> which means I can be certain nobody is using it. >> >> I ha

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

Hi Davey 2016-09-10 1:49 GMT+02:00 Davey Shafik : > Hi all, > > As noted last week, I'm now opening up the vote for adding a PHP Engine > Identifier constant to PHP 7.2+ (and more importantly, to the language > spec). Additionally, there is a second vote to add corresponding > PHP_ENGINE_(*_)VERSI

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

Kalle, My use case is for the php7-mysql-shim, some of the error messages I duplicate and therefore have tests for, are different on HHVM, meaning the tests fail. The messages aren't in the spec, so they're not failing to support the spec, and it's unlikely to affect functionality — which is why

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

Hi! > As noted last week, I'm now opening up the vote for adding a PHP Engine > Identifier constant to PHP 7.2+ (and more importantly, to the language > spec). Additionally, there is a second vote to add corresponding > PHP_ENGINE_(*_)VERSION(_ID) constants. > > https://wiki.php.net/rfc/php_engin

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

On Fri, Sep 9, 2016 at 6:05 PM, Stanislav Malyshev wrote: > Hi! > > > As noted last week, I'm now opening up the vote for adding a PHP Engine > > Identifier constant to PHP 7.2+ (and more importantly, to the language > > spec). Additionally, there is a second vote to add corresponding > > PHP_ENG

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

2016-09-10 3:09 GMT+02:00 Davey Shafik : > Uh… wow. Lemme see if I can fix that without breaking the votes. > > Also, you only voted on the second vote. Was that intentional? Fixed it, voteType should be "single", not "multi" :) -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals -

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

On Fri, Sep 9, 2016 at 6:09 PM, Davey Shafik wrote: > On Fri, Sep 9, 2016 at 6:05 PM, Stanislav Malyshev > wrote: > >> Hi! >> >> > As noted last week, I'm now opening up the vote for adding a PHP Engine >> > Identifier constant to PHP 7.2+ (and more importantly, to the language >> > spec). Addit

Re: [PHP-DEV] [RFC] Make uniqid() more unique

Hi, On Sep 9, 2016 7:50 PM, "Niklas Keller" wrote: > > 2016-09-09 13:48 GMT+02:00 Yasuo Ohgaki : > > > Hi all, > > > > On Fri, Sep 9, 2016 at 8:18 PM, Arvids Godjuks > > wrote: > > > > > > Hm, without "true" you get 13 chars, with "true" - 20+. > > > > Sorry. It's > > > > $ php -r 'var_dump(uniq

Re: [PHP-DEV] Re: VCS Account Request: adambaratz

On Fri, Sep 9, 2016 at 5:14 PM, Ferenc Kovacs wrote: > > > On Fri, Sep 9, 2016 at 5:12 PM, PHP Group wrote: > >> VCS Account Approved: adambaratz approved by tyrael \o/ >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >