Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

2019-04-28 Thread Levi Morrison
On Sun, Apr 28, 2019 at 7:45 PM Stanislav Malyshev wrote: > > Hi! > > > Nikita, impressive leg work; thanks. It validates Bob's intuition from the > > RFC ("... these occurrences are quite rare as it almost always is an error > > in the current form, rendering the impact minimal.") > > If the

[PHP-DEV] Issuing CVEs for PHP

2019-04-28 Thread Stanislav Malyshev
Hi! I have set up PHP as CNA (CVE Identifiers authority) with MITRE. That means that we will be assigning our own CVEs from now on. The process in broad strokes works like this: 1. We request a block of numbers 2. When we have security bug, we use one of the numbers in the block 3. We create CVE

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

2019-04-28 Thread Stanislav Malyshev
Hi! > Nikita, impressive leg work; thanks. It validates Bob's intuition from the > RFC ("... these occurrences are quite rare as it almost always is an error > in the current form, rendering the impact minimal.") If the impact is minimal, why do it at all? So, at the cost of BC break and

Re: [PHP-DEV] Don't silence chr function arguments error

2019-04-28 Thread Sara Golemon
On Sun, Apr 28, 2019 at 6:05 PM Gabriel Caruso wrote: > Currently, if you pass an argument that is not an integer, it will simply > return an empty string: https://3v4l.org/FF2nA. Not entirely accurate. It outputs a one-character string (the null byte). > In case you pass more than > 1

[PHP-DEV] Don't silence chr function arguments error

2019-04-28 Thread Gabriel Caruso
Hello Internals. I'd like to discuss a small change, but that demands a discussion, for a function in PHP's Core: https://php.net/chr . Currently, if you pass an argument that is not an integer, it will simply return an empty string: https://3v4l.org/FF2nA. In case you pass

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread Peter Kokot
Hello, On Wed, 10 Apr 2019 at 12:44, G. P. B. wrote: > > Hello Internals, > > As there have been no further comments the voting for my RFC [1] to > deprecate PHP's > short open tags has started and will run for two (2) weeks. > > Best regards > > George P. Banyard > > [1]

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread G. P. B.
On Sun, 28 Apr 2019 at 14:36, Zeev Suraski wrote: > As I said numerous times in the past, I'm a firm believer that >>> controversial RFCs (ones that generate a lot of votes with a substantial >>> number of opposers) should not pass. I think this is important when >>> adding >>> features - but

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread Stanislav Malyshev
Hi! On 4/28/19 4:52 AM, Benjamin Morel wrote: >> I don't even mind still having a compile error in PHP 8 when it sees the > token I thought one of the arguments for the whole enterprise was to enable http://www.php.net/unsub.php

Re: [PHP-DEV] Revive Number Format Separator RFC

2019-04-28 Thread Theodore Brown
On Sat, Apr 27, 2019 at 10:25 PM Stanislav Malyshev wrote: > I am not exactly against this feature, but the potential for abuse > \- like enabling people using integers for things that are not > integers and should not be stored as integers - worries me now. Based on the usage analysis Bishop

[PHP-DEV] Adding special case for "eval" in disable_functions INI setting

2019-04-28 Thread Benjamin Eberlei
Hi everyone, I have added a patch to introduce a special case for eval when listed in disable_functions INi setting. From a developer perspective it shouldn't be necessary to know that eval is not a function but a language construct. This is why I think this special case is needed rather than

Re: [PHP-DEV] Retiring PHP's Mirror Program

2019-04-28 Thread Derick Rethans
On Sat, 27 Apr 2019, Peter Kokot wrote: > On Mon, 1 Apr 2019 at 16:26, Robert Hickman wrote: > > > > Is there any reason not to use 'php.net' raw without the 'www'? Yes, it has to with DNS delegation. > Additional question: Can we maybe get an insight of a canonical, > recommended URL which

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread Thomas Hruska
On 4/28/2019 4:52 AM, Benjamin Morel wrote: - it allows tools that automatically convert short open tags to standard open tags to actually work on PHP 8. Because if I'm not mistaken, if these tools are based on token_get_all() and " It's very much possible to use token_get_all() with short open

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread Zeev Suraski
On Sun, Apr 28, 2019 at 2:27 PM G. P. B. wrote: > On Sun, 28 Apr 2019 at 10:01, Zeev Suraski wrote: > >> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis wrote: >> >> > Also imo the reason why people write now (and not in the discussion >> > phase) because for some time in the voting there

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread Benjamin Morel
> I don't even mind still having a compile error in PHP 8 when it sees the token I don't have a vote so these are just my 2 cents, but even though I'm all for removing short open tags entirely, I think that this solution is excellent for 2 reasons: - it solves the code leak issue when upgrading

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread G. P. B.
On Sun, 28 Apr 2019 at 10:01, Zeev Suraski wrote: > On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis wrote: > > > Also imo the reason why people write now (and not in the discussion > > phase) because for some time in the voting there wasn't the 2/3 majority > > for the 7.4 (so no sense to

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-28 Thread Zeev Suraski
On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis wrote: > Also imo the reason why people write now (and not in the discussion > phase) because for some time in the voting there wasn't the 2/3 majority > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > votes make the