Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

Hi all, On Fri, Nov 21, 2014 at 6:39 AM, Johannes Schlüter wrote: > > I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using > > multiple default statements in switches (which was accepted, by the > > way). > > > > Updating to PHP 5.7 first gives you more time to prepare for this and

Re: [PHP-DEV] [RFC] Default constructors

thanks Stas. I'll think on next week. Dmitry. On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev wrote: > Hi! > > >> Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive. > >> I think it must be better to use special predefined function (see > >> "zend_pass_function" usage in z

Re: [PHP-DEV] [RFC] Default constructors

Hi! >> Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive. >> I think it must be better to use special predefined function (see >> "zend_pass_function" usage in zend_vm_def.h). I've made a different implementation here: https://github.com/smalyshev/php-src/compare/php:master...s

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

Hi Andrea, On Fri, Nov 21, 2014 at 11:06 AM, Andrea Faulds wrote: > Ideally, usage of these functions should be accompanied by some sort of > validation logic if necessary for the application. They aren’t validation > functions in themselves, they just prevent certain conversions that don’t > ma

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

On 20 November 2014 18:06, Andrea Faulds wrote: > >> On 21 Nov 2014, at 00:45, Adam Harvey wrote: >> >> On 19 November 2014 13:57, Levi Morrison wrote: >>> - The RFC does not address how this is different from >>> FILTER_VALIDATE_* from ext/filter. I know there was a mention of this >>> on the

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

Hi all, On Fri, Nov 21, 2014 at 10:48 AM, Marcio Almada wrote: > > Not a voter, but I don't really see the usefulness of this in core > either. > > True. This could be on packagist or a php ext, but should not be in > core. Main problem is that it carries too much ambiguity between > validation

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

> On 21 Nov 2014, at 01:48, Marcio Almada wrote: > >> Not a voter, but I don't really see the usefulness of this in core either. > > True. This could be on packagist or a php ext, but should not be in > core. Main problem is that it carries too much ambiguity between > validation and coercion w

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

> On 21 Nov 2014, at 00:45, Adam Harvey wrote: > > My -1 is pretty much the same as Levi's: > > On 19 November 2014 13:57, Levi Morrison wrote: >> - The RFC does not address how this is different from >> FILTER_VALIDATE_* from ext/filter. I know there was a mention of this >> on the mailing l

[PHP-DEV] Re: fgetcsv incompatible with fputcsv

> On 21 Nov 2014, at 02:14, Christoph Becker wrote: > > Tjerk Meesters wrote: > >>> On 20 Nov 2014, at 00:26, Christoph Becker wrote: >>> >>> Are you aware of ? It seems this >>> very inconsistency has been reported a few years ago, but has been >>> tag

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

> Not a voter, but I don't really see the usefulness of this in core either. True. This could be on packagist or a php ext, but should not be in core. Main problem is that it carries too much ambiguity between validation and coercion while doesn't solve the real problem: strict typing. -- PHP In

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

Not a voter, but I don't really see the usefulness of this in core either. Sent from my iPhone > On 21 Nov 2014, at 11:45 am, Adam Harvey wrote: > > My -1 is pretty much the same as Levi's: > >> On 19 November 2014 13:57, Levi Morrison wrote: >> - The RFC does not address how this is differ

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

My -1 is pretty much the same as Levi's: On 19 November 2014 13:57, Levi Morrison wrote: > - The RFC does not address how this is different from > FILTER_VALIDATE_* from ext/filter. I know there was a mention of this > on the mailing list, but the RFC should say why a tool that already > exists

Re: [PHP-DEV] [RFC] Safe Casting Functions

Hi Stas, On Fri, Nov 21, 2014 at 1:54 AM, Stas Malyshev wrote: > > Please refer to CWE/SANS TOP 25, Monster Mitigation especially. > > > > http://cwe.mitre.org/top25/#Mitigations > > > > and ISO 27000. (I cannot provide link to it, since one should buy the > > document to read) > > Could you ple

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Thu, 2014-11-20 at 13:54 -0700, Levi Morrison wrote: > > It is a non-trivial change. Fixing this is not always as some people > > might suggest. > > 1) Identify PHP 4 constructors using one of several tools (including > upgrading to PHP 5.7 and getting E_DEPRECATEDs). > 2) Use one of the severa

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On 20 November 2014 20:54:00 GMT, Levi Morrison wrote: >>> I just want to make sure I understand you correctly: you are saying >>> you are voting no on this RFC because a tool, which is not part of >>> this RFC but we kindly provide, doesn't detect when a certain thing >is >>> called? >> >> It is

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

>> I just want to make sure I understand you correctly: you are saying >> you are voting no on this RFC because a tool, which is not part of >> this RFC but we kindly provide, doesn't detect when a certain thing is >> called? > > It is a non-trivial change. Fixing this is not always as some people

Re: [PHP-DEV] [RFC] Safe Casting Functions

Hi! > I brought up ISO 27000 as the definition of IT security, since there are > many > definition for security. ISO 27000 does not define what "security > measure" is, That's exactly the issue. You bring a very generic definitions from standards and best practices, and then you bring your pers

Re: [PHP-DEV] [RFC] Default constructors

Stanislav Malyshev wrote on 20/11/2014 18:47: I do not think the standard should require it, as whoever using this for anything, one way or another, is doing it very, very wrong, but that's how it works now. As I said before, I don't see anything "very, very wrong" about assuming that this cod

Re: [PHP-DEV] [RFC] Default constructors

Hi! > Well, as others have pointed out, HHVM behaves differently in this case, And? > so I guess what I'm getting at is: is this considered a feature *of the > language*, or just a known oddity of the *implementation*? If it's part I do not think the standard should require it, as whoever using

Re: [PHP-DEV] [RFC] Default constructors

Hi! > I think the idea is good. > I'm not sure about implementation. > Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive. > I think it must be better to use special predefined function (see > "zend_pass_function" usage in zend_vm_def.h). I've moved the condition after internal

[PHP-DEV] Re: fgetcsv incompatible with fputcsv

Tjerk Meesters wrote: >> On 20 Nov 2014, at 00:26, Christoph Becker wrote: >> >> Are you aware of ? It seems this >> very inconsistency has been reported a few years ago, but has been >> tagged as "Wont fix" back then. > > Actually that bug report seems to

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

Johannes Schlüter wrote on 20/11/2014 17:00: We can deprecate it in 7 (and fix code in our distribution) and then take a next step in a later version, though. This gives folks like WP time to update their codebase and be ready when our larer version comes out. +1 for officially deprecating this

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Thu, 2014-11-20 at 09:11 -0700, Levi Morrison wrote: > > So I'm -1 on this. > > I just want to make sure I understand you correctly: you are saying > you are voting no on this RFC because a tool, which is not part of > this RFC but we kindly provide, doesn't detect when a certain thing is > cal

Re: [PHP-DEV] [RFC] Safe Casting Functions

Hi! > Please refer to CWE/SANS TOP 25, Monster Mitigation especially. > > http://cwe.mitre.org/top25/#Mitigations > > and ISO 27000. (I cannot provide link to it, since one should buy the > document to read) Could you please be more specific about how this relevant to this specific case? "But an

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Thu, Nov 20, 2014 at 2:43 AM, Johannes Schlüter wrote: > On Wed, 2014-11-19 at 14:33 +, Alain Williams wrote: >> How many servers are stuck on PHP 4 ? >> >> Of those 'stuck' servers, how many have applications still under active >> development ? >> >> The point is: how many people would get

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Thu, Nov 20, 2014 at 10:32 PM, Andrey Andreev wrote: > Hi, > > On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui wrote: >> >> leave it there doesn't hurt anybody. but remove it will. why we need to ? >> > > Leaving it does hurt. Most developers with no PHP4 experience don't > know that such a feat

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

Hi, On Thu, Nov 20, 2014 at 4:25 PM, Xinchen Hui wrote: > > leave it there doesn't hurt anybody. but remove it will. why we need to ? > Leaving it does hurt. Most developers with no PHP4 experience don't know that such a feature exists and spend hours trying to figure out why a parent class' co

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Thu, Nov 20, 2014 at 5:43 PM, Johannes Schlüter wrote: > On Wed, 2014-11-19 at 14:33 +, Alain Williams wrote: >> How many servers are stuck on PHP 4 ? >> >> Of those 'stuck' servers, how many have applications still under active >> development ? >> >> The point is: how many people would get

Re: [PHP-DEV] Re: PHP-FPM state

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 20/11/2014 10:34, Remi Collet a écrit : > P.S. Still TODO: listen_allowed_clients is now aware of IPv4/IPv6, > but it could make sense to make it aware of hostname (using > getaddrinfo), and set all found addresses as allowed. Probably not > urgent

Re: [PHP-DEV] PHP-FPM state

Well, there are two changes there (not sure why "move zlog_set_level() again shows up twice in the log"?) One changes the pm.start_servers calculated default message to a notice (makes total sense IMO). The other moves zlog_set_level() so it's called earlier, or else the log level isn't set ye

Re: [PHP-DEV] PHP SAPI module help

On Thu, 2014-11-20 at 19:19 +0800, 兰 肖鲁 wrote: > How about writing this logic in an extension? Because u can write > your own RSHUTDOWN function to protect your data. Sorry, I have no idea what logic you want to put in a rshutdown and what data you want to protect. And how that relates to this di

Re: [PHP-DEV] PHP SAPI module help

How about writing this logic in an extension? Because u can write your own RSHUTDOWN function to protect your data. sorry for my poor english. -- lanxiaolu 在 2014年11月20日，下午6:30，Johannes Schlüter 写道： > Hi, > > On Tue, 2014-11-18 at 18:08 +0400, Tigran Bayburtsyan wrote: >> I need to execute

Re: [PHP-DEV] [RFC] Safe Casting Functions

Hi Stas, On Thu, Nov 20, 2014 at 4:38 PM, Stanislav Malyshev wrote: > > Please refer to CWE/SANS TOP 25, Monster Mitigation especially. > > > > http://cwe.mitre.org/top25/#Mitigations > > > > and ISO 27000. (I cannot provide link to it, since one should buy the > > document to read) > > Could yo

Re: [PHP-DEV] PHP SAPI module help

Hi, On Tue, 2014-11-18 at 18:08 +0400, Tigran Bayburtsyan wrote: > I need to execute PHP code in some thread of my application and continue > excecution in another. Is is possible to somehow get all global PHP core > hashtables from first thread and restore PHP from that point in another > thread

Re: [PHP-DEV] [RFC] Default constructors

Hi Stas, Sorry, I didn't follow all the discussions. I think the idea is good. I'm not sure about implementation. Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive. I think it must be better to use special predefined function (see "zend_pass_function" usage in zend_vm_def.h). T

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

On Wed, 19 Nov 2014, Andrea Faulds wrote: > Good evening, > > I am putting the Safe Casting Functions RFC to a vote. > > https://wiki.php.net/rfc/safe_cast#vote > > Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29). > > Since some things might have changed since you last

Re: [PHP-DEV] [RFC] Default constructors

Andrea Faulds wrote on 20/11/2014 09:38: On 20 Nov 2014, at 09:34, Rowan Collins wrote: Note that there are many, many places where expressions are actioned for their side effects even though the result is discarded. The following will increment $a 3 times, even though it is discarded each ti

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On Wed, 2014-11-19 at 14:33 +, Alain Williams wrote: > How many servers are stuck on PHP 4 ? > > Of those 'stuck' servers, how many have applications still under active > development ? > > The point is: how many people would get annoyed if PEAR stopped supporting > PHP 4 ? The point about b

Re: [PHP-DEV] [RFC] Default constructors

> On 20 Nov 2014, at 09:34, Rowan Collins wrote: > > Note that there are many, many places where expressions are actioned for > their side effects even though the result is discarded. The following will > increment $a 3 times, even though it is discarded each time: > > $a = 0; > ++$a; // 1 >

Re: [PHP-DEV] [RFC] Default constructors

Stanislav Malyshev wrote on 20/11/2014 00:44: This reminds me of the recent discussion over multiple defaults in a >switch. Perhaps as with that we should phrase the question as "is >there any useful purpose to having the language standardised with >this feature, and conversely is there any reali

Re: [PHP-DEV] Re: PHP-FPM state

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think the situation is now better. At least test suite grow from 3 to 15 tests (+1 for Apparmor) and all recent bugs / changes are covered. Notice: test suite is 5.6+ only as rely on --force-stderr Some minor changes are 5.6+ only 09f9f7ce503097

Re: [PHP-DEV] [RFC] Default constructors

Sharon Levy wrote on 20/11/2014 00:34: As a user, I like this feature since it seems sensible if one is concerned with efficient code execution. Whereas the undefined __construct {} permits the opcode to execute even tho' the resulting value is useless for the class. If anything needs to ch

Re: [PHP-DEV] [RFC] Default constructors

On Thu, Nov 20, 2014 at 9:44 AM, Bradley Weston wrote: > Somehow HHVM has this working http://3v4l.org/5AFSA > > it was mentioned early in the thread that hhvm is not copying the behavior of php for optimizing out the execution of the argument if the constructor doesn't except one. -- Ferenc Ko

Re: [PHP-DEV] [RFC] Default constructors

Somehow HHVM has this working http://3v4l.org/5AFSA On 20/11/2014 00:44, Stanislav Malyshev wrote: Hi! The point of this discussion is that there is an RFC on the table which can be implemented in such a way that it fixes this behaviour (by introducing a default parent, or injecting an empty