Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Kevin Smith]

> 
> On Jan 20, 2016, at 3:20 PM, Derick Rethans  wrote:
> 
> On Wed, 20 Jan 2016, Pavel Kouřil wrote:
> 
>> On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans  
>> wrote:
>>> 
>>> I've decided to re-propose the CoC RFC. There are many reasons for it,
>>> but there are a few points I want to make.
>> 
>> if you still insists on some CoC, maybe you could at least look into 
>> something else than the "Contributor Covenant"?
>> 
>> For example, http://code-of-merit.org/ seems much more reasonable in 
>> "getting the things done" than the Covenant.
> 
> Sure - I would very much appreciate a list of things to look at. Would 
> you have time to suggest a list with C of C's? It is unlikely that one 
> will cover it all anyway. Something that (stolen the idea from twitter) 
> has a good list of *positive* core values is also in my opinion 
> important to have.
> 
> cheers,
> Derick

Hi Derick,

I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW], 
the ironically abusive founder of the Online Abuse Prevention Initiative 
[https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking and 
attempting to eject from projects/employment people she associates with groups 
she doesn’t approve of [http://archive.is/1A8SQ], wherein she suggested that 
you ignore the Code of Merit that Pavel recommended for consideration because 
she associates the author of said code with a group that—though entirely 
unrelated to his Open Source contributions—she finds undesirable and then 
proceeded to make general derogatory comments about him [again, 
https://archive.is/b8RDW].

(My deepest apologies for such a tremendous run-on sentence.)

I certainly hope this isn’t indicative of the spirit of this proposal. This 
exchange really seems to suggest the goal of these codes in general, and now 
possibly this one in particular, is what so many of us have feared: to exclude 
people with wrong ideas and associations, as defined by the in-group.


Kevin Smith
Hearsay Interactive 

[PHP-DEV] Severe safety fail in file access and stream filters

[Umberto Salsi]

Dear internal developers,

I recently discovered several failures in error detection involving
file access, stream compression and source inclusion that may bring the
program to process missing or invalid data (very severe safety bug) or
simply crash without apparent reason. I reported all these issues with
their test script trying to do as much as I can to really understand
what happen here. I think it's the time for some real internal expert
to take over these issues and kindly reply to the following questions:

1. Is there something very basic I'm missing? I'm doing something wrong?

2. If yes, what can I do to fix so that i/o errors can be detected?

3. If no, why i/o errors do not propagate through the engine, but are
   mostly ignored? and why the user's program does not get signaled
   about this, and keeps receiving empty strings or garbage instead?

There is the chance to close all these:

fread() does not detect file access error
https://bugs.php.net/bug.php?id=71384
(Also includes disk image containing a damaged file for testing.)

require* and include* do not detect input/output error
https://bugs.php.net/bug.php?id=71385
(Probably related to the bug above.)

fread() does not detect decoding errors from filter zlib.inflate
https://bugs.php.net/bug.php?id=71417
(Probably missing propagation of errors through streams.)

fread() does not detects decoding errors from filter bzip2.decompress
https://bugs.php.net/bug.php?id=71263
(Probably the same as above.)

Fix for zlib.deflate and zlib.inflate filters; fix for example #1
https://bugs.php.net/bug.php?id=68556
(This latter is actually a doc problem, but it also shows how much is
difficult to explain to the user what exactly happens if something goes
wrong and how to make safe applications).


Regards,
 ___ 
/_|_\  Umberto Salsi
\/_\/  www.icosaedro.it


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

[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #69111 (Crash in SessionHandler::read()). Made session save handler abuse much harder than before.: NEWS ext/session/mod_user.c ext/session/mod_user_clas

[Yasuo Ohgaki]

Hi all,

On Fri, Jan 15, 2016 at 3:50 PM, Yasuo Ohgaki  wrote:
> Commit:bfb9307b2d679a91e138fd876880470ece60942b
> Author:Yasuo Ohgaki  Fri, 15 Jan 2016 13:47:45 
> +0900
> Parents:   d7f8d9e3a9babf0e4f0c1a5590e1feb5e69bd84a
> Branches:  PHP-5.6 PHP-7.0 master
>
> Link:   
> http://git.php.net/?p=php-src.git;a=commitdiff;h=bfb9307b2d679a91e138fd876880470ece60942b
>
> Log:
> Fixed bug #69111 (Crash in SessionHandler::read()).
> Made session save handler abuse much harder than before.
>
> Bugs:
> https://bugs.php.net/69111
>
> Changed paths:
>   M  NEWS
>   M  ext/session/mod_user.c
>   M  ext/session/mod_user_class.c
>   M  ext/session/session.c
>   M  ext/session/tests/bug55688.phpt
>   M  ext/session/tests/bug60634.phpt
>   M  ext/session/tests/bug60634_error_1.phpt
>   M  ext/session/tests/bug60634_error_5.phpt
>   M  ext/session/tests/bug67972.phpt
>   A  ext/session/tests/bug69111.phpt
>   M  ext/session/tests/sessionhandler_open_001.phpt

I recently fixed crash bug by session save handler abuse. It became
much harder to abuse save handler callbacks, but it's not complete
because current session module does not check bailout from user
handler.

For instance,
http://lxr.php.net/xref/PHP_MASTER/ext/session/session.c#2128
s_read() calls user script read handler, but mod_user*.c does not use
zend_try() for it.
http://lxr.php.net/xref/PHP_MASTER/ext/session/mod_user.c#131

User handler uses zend_try few places in mod_user*.c, but it does
not use zend_try where it is required. The reason why zend_try is
not used is save handler code should not touch session module
internal data structures. i.e. Variable cleanups are needed in some
places and it results in needless save handler calls on error in
limited case.

I may use zend_try in session.c rather than mod_user*.c.
This way, I can do all cleanup tasks required up on errors.
Downside is a little overhead of zend_try macros. zend_try is not
required for native save handlers at all.

We have 4 options
 - Don't care. Error shouldn't happen under normal circumstances.
(Leave as it is now)
 - Use zend_try in session.c (Unneeded overhead for native handlers)
 - Use zend_try in mod_user*.c, if EG(bailout) is changed, call
zend_bailout() from session.c.
 - Use flag if session.c should use zend_try or not. (Code will look
ugly, but it works)

I would like to hear which option is preferred, not preferred.
I don't have preference. If nobody cares, I'll leave it as is.

Thanks.

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Pierre Joye]

On Jan 21, 2016 2:38 AM, "Paul M. Jones"  wrote:
>
>
> > On Jan 20, 2016, at 13:04, Derick Rethans 
wrote:
> >
> > Hi,
> >
> > I've decided to re-propose the CoC RFC.
>
> Is it a violation of the RFC rules to skip step 1 ("Email
internals@lists.php.net to measure reaction to your intended proposal") and
go straight to step 3 ("Create the RFC") ?
>
>   
>
> At the very least, it seems like an initial email needs to be sent before
putting the RFC on the wiki.
>

It is as far as I can tell  not a violation as it is a take over.

[PHP-DEV] [RFC][VOTE] OpenSSL AEAD support

[Jakub Zelenka]

Hi,

The vote is now open:

https://wiki.php.net/rfc/openssl_aead#voting

Cheers

Jakub

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-01-20

[lp_benchmark_robot]

Results for project PHP master, build date 2016-01-20 06:29:57+02:00
commit: dcf3db6
previous commit:8e60e0c
revision date:  2016-01-19 22:26:32+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.23%  0.03%  0.63%  
  6.80%
:-|   Drupal 7.36 cgi -T1  0.18%  0.03% -0.22%  
  5.09%
:-|   MediaWiki 1.23.9 cgi -T5000  0.00%  0.00%  0.51%  
  2.85%
:-|   bench.php cgi -T100  0.04% -0.00%  0.24%  
  5.83%
:-|  micro_bench.php cgi -T10  0.06% -0.04%  0.48%  
  3.90%
:-|  mandelbrot.php cgi -T100  0.01% -0.03%-11.60%  
  0.43%
---
* Relative Standard Deviation (Standard Deviation/Average)

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

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] [RFC] [Withdrawn] Adopt Code of Conduct

[Anthony Ferrara]

All,

I've decided to withdraw the CoC RFC. There are many reasons for it,
but there are a few points I want to make.

As to the content of the RFC, when I initially proposed it, I selected
the Contributor Covenant due to it being a well adopted standard.
Several people raised objections to it, and I was completely open to
changing it. But the more objections I see, the more I feel the nature
of the objections actually justifies the Covenant as the choice rather
than justifies switching it. The more I hear people complain about the
"scope of applicability" being outside the project, the more it's
apparent that many (not all, but many) simply don't want to need to
think about their actions in other contexts. Some will claim that
ambiguity will lead to abuse, but the underlying idea is "treat people
with respect". And as long as you do that, all will be fine.

And while several would rather see a CoC that focuses on "positive
behavior", to me that's not what a CoC is for. The CoC is to take a
stand and say "this is what we will not tolerate". Positive behavior
should be encourage in another "Contributing" document. Where you
detail how people should contribute. The CoC is a mechanism for people
to feel safe. And safety is achieved by taking a stand.

As far as voting on just the CoC without a private reporting mechanism
(which implies some degree of "teeth"), I've made it clear that I
don't believe that's tenable. I believe that asking people to go
public with every incident defeats the entire point of having a CoC.

I am also not happy with the RFC in its current state (I've been clear
about that since day one). But I also have no further energy to evolve
it further. Hence, there is nothing left for me to do but withdraw it.

Thanks

Anthony

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

[PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Derick Rethans]

Hi,

I've decided to re-propose the CoC RFC. There are many reasons for it, 
but there are a few points I want to make.

I strongly believe that a Code of Conduct is required. The amount of 
toxic behaviour on this list is in my opinion unacceptable. It drives 
people away, it certainly did. It is also one of the reasons I am not 
nearly as active as I used to be.

It also makes me reluctant to welcome and mentor new people wanting to 
contribute. I have said "no" to two people in the last few days, mostly 
because I am not sure whether I want them exposed to some of the things 
being said on the list.

But I think this list, and hence this project, and language, can be 
improved. A Code of Conduct alone is not enough. The focus for this 
list, and wider community, should be on collaborating to make PHP even 
better and faster than it already is. Collaboration works better in a 
happy environment, where people work together instead of against 
eachother.

The new 0.5 version of the RFC that is up at 
https://wiki.php.net/rfc/adopt-code-of-conduct focusses more on working 
together and mediation than on acting with an iron fist on when things 
go awry, although these parts of the RFC are still included. In my 
opinion, an CoC that is not enforced is nothing but some text on a piece 
of paper—or in our case, a few bits on a disk. I have added a section, 
Constructive Contributor Guidelines, in addition to the CoC. This 
section definitely needs improving.

I would everybody invite you to help out improving this RFC, but please 
take into account 
https://wiki.php.net/rfc/adopt-code-of-conduct#constructive_collaboration_guidelines
 

I want this to work, and work together, to get this approved. 

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

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

[Andrea Faulds]

Hi Pascal,

Pascal MARTIN, AFUP wrote:

Le 13/01/2016 19:48, Thomas Punt a écrit :

Voting has opened for the inclusion of a digit separator in PHP[1].
Voting ends in
one week's time on January 20th.


Hi,

At AFUP, we would be on the -1 side (by a huge margin).

The "good" thing would be code that's a bit more readable, yes.

But it would be harder to search in code, as there would be more than
one way to write a number. Basically, it would break grep/find.

Splitting numbers so they are more readable is kind of a presentation
matter and, as such, could be done by an editor/IDE when displaying
code, without having to modify the code by hand (actually, I'm quite
surprised it's not a feature I remember seeing in any IDE).

In any case, thanks for you work on this!


One other approach I thought of is to use constant scalar expressions:

+('123'.'456'.'789')

It's not quite the same of native support, but it works.

Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Paul M. Jones]

> On Jan 20, 2016, at 13:04, Derick Rethans  wrote:
> 
> Hi,
> 
> I've decided to re-propose the CoC RFC.

Is it a violation of the RFC rules to skip step 1 ("Email 
internals@lists.php.net to measure reaction to your intended proposal") and go 
straight to step 3 ("Create the RFC") ?

  

At the very least, it seems like an initial email needs to be sent before 
putting the RFC on the wiki.



-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php



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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Andreas Heigl]

Am 20.01.16 um 20:04 schrieb Derick Rethans:
> Hi,
> 
> I've decided to re-propose the CoC RFC. There are many reasons for it, 
> but there are a few points I want to make.
> 
> I strongly believe that a Code of Conduct is required. The amount of 
> toxic behaviour on this list is in my opinion unacceptable. It drives 
> people away, it certainly did. It is also one of the reasons I am not 
> nearly as active as I used to be.
> 
> It also makes me reluctant to welcome and mentor new people wanting to 
> contribute. I have said "no" to two people in the last few days, mostly 
> because I am not sure whether I want them exposed to some of the things 
> being said on the list.
> 
> But I think this list, and hence this project, and language, can be 
> improved. A Code of Conduct alone is not enough. The focus for this 
> list, and wider community, should be on collaborating to make PHP even 
> better and faster than it already is. Collaboration works better in a 
> happy environment, where people work together instead of against 
> eachother.
> 
> The new 0.5 version of the RFC that is up at 
> https://wiki.php.net/rfc/adopt-code-of-conduct focusses more on working 
> together and mediation than on acting with an iron fist on when things 
> go awry, although these parts of the RFC are still included. In my 
> opinion, an CoC that is not enforced is nothing but some text on a piece 
> of paper—or in our case, a few bits on a disk. I have added a section, 
> Constructive Contributor Guidelines, in addition to the CoC. This 
> section definitely needs improving.
> 
> I would everybody invite you to help out improving this RFC, but please 
> take into account 
> https://wiki.php.net/rfc/adopt-code-of-conduct#constructive_collaboration_guidelines
>  
> 
> I want this to work, and work together, to get this approved. 
> 
> cheers,
> Derick

Thank you Derick for stepping up!

I would have done it myself but you've been faster ;)

Let's work this out all together!

Cheers

Andreas




-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Derick Rethans]

Hi,

In order to make suggestions to the wording of the RFCs, and included 
Contributer Covenant and Guideslines easier, I've imported it into 
GitHub:

https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst

If you have specific suggestions, they're more than welcome there 
through Pull Requests and comments (and issues). Hopefully, it makes it 
easier to track things down, and keep it managable.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> In order to make suggestions to the wording of the RFCs, and included 
> Contributer Covenant and Guideslines easier, I've imported it into 
> GitHub:
> 
> https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst

Great idea. Unfortunately, I don't see any way in Github to comment
per-line on the actual text, only on patches. I'll try to do that but I
wonder if there's a better way.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> You can't do it on the /blob/ view, but if you click on the commit to
> get to the /commit/ view, you can comment on that. :)

Right. That's what I meant by "patches". But that only specific commit,
not the whole result, right?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Andrea Faulds]

Hi Paul,

Paul M. Jones wrote:



On Jan 20, 2016, at 13:04, Derick Rethans  wrote:

Hi,

I've decided to re-propose the CoC RFC.


Is it a violation of the RFC rules to skip step 1 ("Email internals@lists.php.net to measure 
reaction to your intended proposal") and go straight to step 3 ("Create the RFC") ?

   

At the very least, it seems like an initial email needs to be sent before 
putting the RFC on the wiki.


The howto isn't really a set of rules, more guidelines on how to do an 
RFC. The actual hard rules as such are contained in the voting and 
release process RFCs, among others.


It's not uncommon for people to propose RFCs without a prior mailing 
list dicussion.


Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Derick Rethans]

On Wed, 20 Jan 2016, Pavel Kouřil wrote:

> On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans  
> wrote:
> >
> > I've decided to re-propose the CoC RFC. There are many reasons for it,
> > but there are a few points I want to make.
> 
> if you still insists on some CoC, maybe you could at least look into 
> something else than the "Contributor Covenant"?
> 
> For example, http://code-of-merit.org/ seems much more reasonable in 
> "getting the things done" than the Covenant.

Sure - I would very much appreciate a list of things to look at. Would 
you have time to suggest a list with C of C's? It is unlikely that one 
will cover it all anyway. Something that (stolen the idea from twitter) 
has a good list of *positive* core values is also in my opinion 
important to have.

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Benjamin Eberlei]

On Wed, Jan 20, 2016 at 8:37 PM, Paul M. Jones  wrote:

>
> > On Jan 20, 2016, at 13:04, Derick Rethans 
> wrote:
> >
> > Hi,
> >
> > I've decided to re-propose the CoC RFC.
>
> Is it a violation of the RFC rules to skip step 1 ("Email
> internals@lists.php.net to measure reaction to your intended proposal")
> and go straight to step 3 ("Create the RFC") ?
>
>   
>
> At the very least, it seems like an initial email needs to be sent before
> putting the RFC on the wiki.
>

Step 1 and 2 are for newcomers, specifically step 1 is about measuring if a
new feature is going to be implemented by some contributor or by the
proposer or just an idea. Since the RFC is not about code and also just
re-opened and not new, they don't really apply imho.


>
>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Ferenc Kovacs]

On Wed, Jan 20, 2016 at 8:37 PM, Paul M. Jones  wrote:

>
> > On Jan 20, 2016, at 13:04, Derick Rethans 
> wrote:
> >
> > Hi,
> >
> > I've decided to re-propose the CoC RFC.
>
> Is it a violation of the RFC rules to skip step 1 ("Email
> internals@lists.php.net to measure reaction to your intended proposal")
> and go straight to step 3 ("Create the RFC") ?
>
>   
>
> At the very least, it seems like an initial email needs to be sent before
> putting the RFC on the wiki.


for the record that is a guideline, which was edited over the years by
multiple people (mostly for the better), but that was never voted and have
no binding.
for the official rules about the actual rules for an rfc see
https://wiki.php.net/rfc/voting which states:
"Proposal is formally initiated by creating an RFC on PHP wiki and
announcing it on the list."
(but in this case it is even more easier because this isn't a new rfc just
a draft rfc getting taken over by another volunteer after the original
proposer stepped down)

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[PHP-DEV] RE: [RFC][VOTE] Number Format Separator

[Thomas Punt]

Hi internals!

> Voting has opened for the inclusion of a digit separator in PHP[1]. Voting 
> ends in
> one week's time on January 20th.

Voting has now ended with 20 for and 18 against. This means the RFC has been
declined.

Thank you to all who participated in the RFC discussion and voting!

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Derick Rethans]

On Wed, 20 Jan 2016, Stanislav Malyshev wrote:

> > You can't do it on the /blob/ view, but if you click on the commit 
> > to get to the /commit/ view, you can comment on that. :)
> 
> Right. That's what I meant by "patches". But that only specific commit,
> not the whole result, right?

Correct - seems you found it though :-)

cheers,
Derick

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

AW: [PHP-DEV] [RFC] Allow specifying keys in list()

[Robert Stoll]

Hi Andrea

I am writing you in private since I think this is rather out of scope.

 -Ursprüngliche Nachricht-
> Von: Pierre Joye [mailto:pierre@gmail.com]
> Gesendet: Montag, 18. Januar 2016 05:54
> An: Andrea Faulds
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Allow specifying keys in list()
> 
> hi Andrea,
> 
> I very much like this proposal. Good work as usual!
> 
> The only part where I think we should not rely on list is the future scope. I 
> can see the logic that leads to use list for named
> arguments.
> However I really think it is a very different topic and having to use list to 
> define arguments, it sounds like a hack to solve
> another long due feature. 

I agree with Pierre on this one. Using list for named parameters seems like a 
lot of overhead on the declaration side to me (writing the name of a parameter 
twice). IMO it should not require additional effort than writing a 
function/method today and it should be available for all functions/methods and 
not only for ones with special named-paramater-syntax. I think you should 
consider further (when thinking about using the new feature for named 
parameters)
- how can you specify optional parameters?
- how can you specify byRef parameters?
- what happens if one does not provide all keys? Currently this: list($a, $b) = 
[1]; //only produces a Warning
- are there differences between strict mode and none strict mode?  e.g., what 
if the type of the key is different?
- would it be possible to use a type for the key as well (as for the value 
indicated in your RFC)?
- would you allow nested destructuring for parameters?
- how would you reduce the overhead of creating an array which is then copied 
and passed to the function?

IMO destructuring parameters and named parameters are two different things 
which could be combined. Something like this:
function foo(SomeClass $class, list("x" => $x, "y" => $y) $point = ["x"=>0, 
"y"=>0], $flagA = true, $flagB = 1) {
}
foo($myClass, point: [1,2], flagB: 0);
foo($myClass, flagB: 2);

yet, IMO it would hamper readability (probably in many cases) and it would be 
better to do it inside the function.
I understand destructuring parameters just as syntactic sugar and I would still 
expect that PhpDocumenter would indicate that my function requires an array. 
Otherwise the same feature would suddenly also be used to declare deep 
structured data structures and at this point I am not so sure whether auto 
conversion of keys play well together with strict mode. It would certainly be 
interesting from a type safety point of view that one can define very complex 
data structures and let PHP do the work for verification. Yet, it also opens a 
door to very ugly code (well... which also exists without the feature) -- 
sorry, drifting away from the topic. 

Some other points crossing my mind
- how well does the feature interact with typed arrays (if they should be 
introduced at some point)?
- how well does it interact with structural types (if they should be introduced 
at some point)?

And now some points to the RFC:
- I like the RFC in general
- I am not really a fan of the naming "list" in general but I think it is 
appropriate to reuse the same syntax for this task.
- one thing I am missing in the RFC is error handling. What happens if a key is 
not found? And there are surely other questions. I think you should include a 
section about error handling in the RFC.
- I guess mixing number keys with string keys is possible, right?
- are placeholders (something like list(_ , $a, _) = [1,2,3])  in your pipeline 
or do you think they make no sense in PHP?
- already an idea how it would interact with pattern matching? 

Cheers,
Robert




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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:

Hi!


In order to make suggestions to the wording of the RFCs, and included
Contributer Covenant and Guideslines easier, I've imported it into
GitHub:

https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst


Great idea. Unfortunately, I don't see any way in Github to comment
per-line on the actual text, only on patches. I'll try to do that but I
wonder if there's a better way.


You can't do it on the /blob/ view, but if you click on the commit to 
get to the /commit/ view, you can comment on that. :)


--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Pavel Kouřil]

On Wed, Jan 20, 2016 at 8:04 PM, Derick Rethans  wrote:
> Hi,
>
> I've decided to re-propose the CoC RFC. There are many reasons for it,
> but there are a few points I want to make.
>
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Hello,

if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?

For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.

Regards
Pavel Kouril

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

[PHP-DEV] WIKI: phpng-upgrading

[Yasuo Ohgaki]

Hi ZendEngine developers,

I'm not sure if the wiki page is maintained, but I noticed few errors.

https://wiki.php.net/phpng-upgrading#strings
has following example.

- ZVAL_STRING(zv, str, 1);
+ ZVAL_STRING(zv, str);

- ZVAL_STRINGL(zv, str, len, 1);
+ ZVAL_STRINGL(zv, str, len);

- ZVAL_STRING(zv, str, 0);
+ ZVAL_STRING(zv, str);
+ efree(str);

- ZVAL_STRINGL(zv, str, len, 0);
+ ZVAL_STRINGL(zv, str, len);
+ efree(str);

Since PHP5 has following definition for ZVAL_STRING*()

#define ZVAL_STRING(z, s, duplicate) do {\
const char *__s=(s);\
zval *__z = (z);\
Z_STRLEN_P(__z) = strlen(__s);\
Z_STRVAL_P(__z) = (duplicate?estrndup(__s,
Z_STRLEN_P(__z)):(char*)__s);\
Z_TYPE_P(__z) = IS_STRING;\
} while (0)

the example's 0 and 1 are flipped, efree() locations are wrong.

In https://wiki.php.net/phpng-upgrading#zend_string_api ,
it says

zend_string_init(char *val, int len, int persistent)

Current definition is

zend_string_init(char *val, size_t len, int persistent)

Should I update the doc or is the doc is maintained
elsewhere?

Regards

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

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

[Yasuo Ohgaki]

Hi Andrea,

On Thu, Jan 21, 2016 at 4:18 AM, Andrea Faulds  wrote:
>
> One other approach I thought of is to use constant scalar expressions:
>
> +('123'.'456'.'789')
>
> It's not quite the same of native support, but it works.

This is what I do on occasions.

I have to read var_export()ed PHP code sometimes.
If PHP supports this RFC and var_export() support it,
it would be much easier to read.

It's irrelevant for this RFC, but if PHP supports compile
time string concatenation

echo "Very long sting "
"that is concatenated "
"at compile time.";

It would be nice to have.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] WIKI: phpng-upgrading

[Sean DuBois]

On Thu, Jan 21, 2016 at 06:55:41AM +0900, Yasuo Ohgaki wrote:
> Hi ZendEngine developers,
>
> I'm not sure if the wiki page is maintained, but I noticed few errors.
>
> https://wiki.php.net/phpng-upgrading#strings
> has following example.
>
> - ZVAL_STRING(zv, str, 1);
> + ZVAL_STRING(zv, str);
>
> - ZVAL_STRINGL(zv, str, len, 1);
> + ZVAL_STRINGL(zv, str, len);
>
> - ZVAL_STRING(zv, str, 0);
> + ZVAL_STRING(zv, str);
> + efree(str);
>
> - ZVAL_STRINGL(zv, str, len, 0);
> + ZVAL_STRINGL(zv, str, len);
> + efree(str);
>
> Since PHP5 has following definition for ZVAL_STRING*()
>
> #define ZVAL_STRING(z, s, duplicate) do {\
> const char *__s=(s);\
> zval *__z = (z);\
> Z_STRLEN_P(__z) = strlen(__s);\
> Z_STRVAL_P(__z) = (duplicate?estrndup(__s,
> Z_STRLEN_P(__z)):(char*)__s);\
> Z_TYPE_P(__z) = IS_STRING;\
> } while (0)
>
> the example's 0 and 1 are flipped, efree() locations are wrong.
>
> In https://wiki.php.net/phpng-upgrading#zend_string_api ,
> it says
>
> zend_string_init(char *val, int len, int persistent)
>
> Current definition is
>
> zend_string_init(char *val, size_t len, int persistent)
>
> Should I update the doc or is the doc is maintained
> elsewhere?
>
> Regards
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi!

I tried to get access to that page as well, but didn't have any luck
would you mind adding the zend_parse_paramaters changes?

'l' went from 'long' -> 'zend_long' and 's' went from 'int' -> 'size_t'.

So many extensions have been ported without this in mind, and it bites
in really nasty hard to reproduce runtime ways.

thanks!

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

[PHP-DEV] GnuPG support for Phar Signatures

[Flyingmana]

With OpenSSL Phar already supports one public/private key algorithm.
As using Phars as command line tools is in principle a question of
Trust, a Trust based Identity Tool like GnuPG looks like a good match
for me.

Iam already aware, that it would probably only work for people, who
installed the GnuPG extension for php.

Why I think this feature makes sense:
Tools like Composer are an important part of PHP projects today, but
people often use it in not complete secure ways. For example it is often
writeable by the current user, where it is easy to mess around with the
content of phars. And there is currently no way to detect, if someone
messed with it, as all existing signatures are easy to mess analog with it.
For GnuPG you have the keyring in a secure place, which can not get
messed with.
A problem I see here, how it could be enforced to verify via GnuPG, as
an attacker could also change the used algorithm.

Now My Questions are:
 * Do I need/should to modify the Phar code to support this new type?
 * should the main logic be part of the Phar code, the GnuPG extension,
or a complete new one?
 * is there someone I should talk about this before to get maybe
valuable knowledge?
 * Anything else I should look out for?

Best Regards
Flyingmana

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

Re: [PHP-DEV] WIKI: phpng-upgrading

[François Laupretre]

Le 20/01/2016 23:07, Sean DuBois a écrit :

On Thu, Jan 21, 2016 at 06:55:41AM +0900, Yasuo Ohgaki wrote:

Hi ZendEngine developers,

I'm not sure if the wiki page is maintained, but I noticed few errors.

https://wiki.php.net/phpng-upgrading#strings
has following example.

- ZVAL_STRING(zv, str, 1);
+ ZVAL_STRING(zv, str);

- ZVAL_STRINGL(zv, str, len, 1);
+ ZVAL_STRINGL(zv, str, len);

- ZVAL_STRING(zv, str, 0);
+ ZVAL_STRING(zv, str);
+ efree(str);

- ZVAL_STRINGL(zv, str, len, 0);
+ ZVAL_STRINGL(zv, str, len);
+ efree(str);

Since PHP5 has following definition for ZVAL_STRING*()

#define ZVAL_STRING(z, s, duplicate) do {\
 const char *__s=(s);\
 zval *__z = (z);\
 Z_STRLEN_P(__z) = strlen(__s);\
 Z_STRVAL_P(__z) = (duplicate?estrndup(__s,
Z_STRLEN_P(__z)):(char*)__s);\
 Z_TYPE_P(__z) = IS_STRING;\
 } while (0)

the example's 0 and 1 are flipped, efree() locations are wrong.

In https://wiki.php.net/phpng-upgrading#zend_string_api ,
it says

zend_string_init(char *val, int len, int persistent)

Current definition is

zend_string_init(char *val, size_t len, int persistent)

Should I update the doc or is the doc is maintained
elsewhere?

Regards

--
Yasuo Ohgaki
yohg...@ohgaki.net

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



Hi!

I tried to get access to that page as well, but didn't have any luck
would you mind adding the zend_parse_paramaters changes?

'l' went from 'long' -> 'zend_long' and 's' went from 'int' -> 'size_t'.

So many extensions have been ported without this in mind, and it bites
in really nasty hard to reproduce runtime ways.

thanks!



May I suggest we also include in this document a pointer to the PECL 
compatibility library (https://github.com/flaupretre/pecl-compat), a 
compatibility layer for PHP 5 & 7.


Of course, this is not solving every issues but it can help a lot, 
especially on string/array-related issues. Among others, it includes a 
solution to the zend_parse_parameters() issue (using 
COMPAT_ARG_SIZE_T/COMPAT_ARG_LONG_T as variable types).



Regards

François


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

[PHP-DEV] Re: WIKI: phpng-upgrading

[Andrea Faulds]

Hi Yasuo,

Yasuo Ohgaki wrote:

Hi ZendEngine developers,

I'm not sure if the wiki page is maintained, but I noticed few errors.

https://wiki.php.net/phpng-upgrading#strings


phpng-upgrading was written back when it was just phpng and the 64-bit 
patch wasn't merged. Heck, I don't think phpng was merged into master at 
that point either.


Given it's now needed for PHP 7 migration, maybe we should move it into 
UPGRADING.INTERNALS or onto the PHP manual?


Thanks.
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> I've decided to re-propose the CoC RFC. There are many reasons for it, 
> but there are a few points I want to make.
> 
> I strongly believe that a Code of Conduct is required. The amount of 
> toxic behaviour on this list is in my opinion unacceptable. It drives 
> people away, it certainly did. It is also one of the reasons I am not 
> nearly as active as I used to be.

Thanks for continuing the discussion. I'd like however to point out that
one of the major points of contention, as I see it - that it is not at
all clear how having CoC prohibiting things like "the use of sexualized
language" and "trolling", would help with "toxic behavior". I want to be
very clear, because I feel this concern is not being understood, so I
will try to outline it as detailed as I can, please excuse the verbosity:

1. I do not think literally anybody wants to see trolling or sexual
language attacks, or harassment, etc. on the list. I think we all agree
this is unacceptable.

2. I think most of the people here know that the list has been not the
friendliest place ever, and most of the people here would like to
improve that.

3. I do not think we do have now or ever had a significant problem with
behaviors described by "Code of Conduct Text". I think the problem
described may be caused by other set of behaviors, not covered by "Code
of Conduct Text".

4. Given that, it is not clear to me, and apparently some other folks
too, how banning those (as universally agreed) despicable behaviors is
going to lead to any improvement on the matter of "toxic".

5. Since so many people somehow did not understand that, judging by
their comments, this does not mean anybody thinks it is OK to behave
that way (see 1). It means that it appears we are trying very hard to
fix not the same place that is claimed to be broken.
Now, it can be that *both* places are broken, or that the fix can be
applied as a preventive measure - and both are fine. But arguing "we
have problem X therefore let's apply fix for a different problem Y"
sounds strange to me.

I think clarifying that matter would help.

Also, there was a complaint that there has been too much critique and
not enough constructive proposals. I think there is some truth to that,
as it is much easier to find bugs than to develop things, and much more
people submit bug reports than fix them. This is natural, but this
certainly could use improvement. In that spirit, I would like to
reiterate the proposal of handling CoC matters that I personally think
would be the best. This is my personal approach, so please feel free to
amend, criticize and disagree.

1. Make a values statement, along the lines of:
https://www.drupal.org/dcoc
https://www.djangoproject.com/conduct/
https://www.freebsd.org/internal/code-of-conduct.html
https://meta.wikimedia.org/wiki/Grants:Friendly_space_expectations

This document should emphasize behaviors we want to achieve and
reinforce, not be just a catalog of behaviors we hate.

In this document, as one paragraph, include "unacceptable behavior"
statement from current RFC, verbatim or suitably modified (that of
course does not preclude including other parts of it in other paragraphs).

"Constructive Collaboration Guidelines" probably should be part of this
document too - and be stated before the unacceptable part. I know it
sound like nitpicking but I think tone of the documents is important and
if we start with negatives (even by rejecting them) it sets different
tone than if we start with positive. It's one thing to welcome people to
your house with "Welcome, friend, feel at home!" and another with
"Please don't steal my wallet and don't kick my dog!"

2. Create a conflict resolution team whose stated purpose is to resolve
conflicts (note: not punish or exclude!) which impact the project and
impede or disrupt the collaboration.

3. Separately from the document above, have a conflict resolution
policy, which describes how the CRT above is elected, how it resolves
issues, what are the confidentiality guidelines, what are processes for
creating bans & appeals, etc.

I know not everybody agrees, but I think it is much more beneficial to
have this in a separate document and if possible, as a separate RFC,
since discussion about it is substantially different from (1) and
partially from (2) - principal agreement on having such team is much
more important, IMO, than figuring out how long it can ban people for.

That would also make discussion a bit more manageable, as discussing at
the same time two different things: do we want CoC and the particular
details of CRT behavior we want. I think separating these discussion
would allow us to emphasize things we agree on and formalize them
quickly, and hash out the details without the concern that small
disagreements would derail the whole process.

If this looks good to anybody, I can take the time to actually arrange
the texts - though English not being my naive language, I am not the
best person for copy-writing. But I 

Re: [PHP-DEV] WIKI: phpng-upgrading

[Yasuo Ohgaki]

Hi Nikita,

On Thu, Jan 21, 2016 at 7:28 AM, Nikita Popov  wrote:
> These examples are correct. In PHP 7 ZVAL_STRING always duplicates, which is
> what the 1 parameter used to signify.

Oh, now I see the example intention.
Thank you.

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: AW: [PHP-DEV] [RFC] Allow specifying keys in list()

[Thomas Bley]

Hi Robert,

for named parameters, I would prefer this syntax over list():

function foo($foo, [a: string $a, b: int &$b, c: bool $c = true]) {
... work with $foo, $a, $b, $c
}

$b = 42;
foo('foo', ['a' => 'bar', 'b' => $b]);


function bar($foo, SomeClass {a: string $a, b: int &$b, c: bool $c = true}) {
... work with $foo, $a, $b, $c
}

$o = new SomeClass();
$o->a = 'bar';
$o->b = 42;
bar('foo', $o);

Regards
Thomas

Robert Stoll wrote on 20.01.2016 22:20:

> Hi Andrea
> 
> I am writing you in private since I think this is rather out of scope.
> 
> -Ursprüngliche Nachricht-
>> Von: Pierre Joye [mailto:pierre@gmail.com]
>> Gesendet: Montag, 18. Januar 2016 05:54
>> An: Andrea Faulds
>> Cc: PHP internals
>> Betreff: Re: [PHP-DEV] [RFC] Allow specifying keys in list()
>> 
>> hi Andrea,
>> 
>> I very much like this proposal. Good work as usual!
>> 
>> The only part where I think we should not rely on list is the future scope. I
>> can see the logic that leads to use list for named
>> arguments.
>> However I really think it is a very different topic and having to use list to
>> define arguments, it sounds like a hack to solve
>> another long due feature. 
> 
> I agree with Pierre on this one. Using list for named parameters seems like a
> lot of overhead on the declaration side to me (writing the name of a parameter
> twice). IMO it should not require additional effort than writing a
> function/method today and it should be available for all functions/methods and
> not only for ones with special named-paramater-syntax. I think you should
> consider further (when thinking about using the new feature for named
> parameters)
> - how can you specify optional parameters?
> - how can you specify byRef parameters?
> - what happens if one does not provide all keys? Currently this: list($a, $b) 
> =
> [1]; //only produces a Warning
> - are there differences between strict mode and none strict mode?  e.g., what
> if the type of the key is different?
> - would it be possible to use a type for the key as well (as for the value
> indicated in your RFC)?
> - would you allow nested destructuring for parameters?
> - how would you reduce the overhead of creating an array which is then copied
> and passed to the function?
> 
> IMO destructuring parameters and named parameters are two different things
> which could be combined. Something like this:
> function foo(SomeClass $class, list("x" => $x, "y" => $y) $point = ["x"=>0,
> "y"=>0], $flagA = true, $flagB = 1) {
> }
> foo($myClass, point: [1,2], flagB: 0);
> foo($myClass, flagB: 2);
> 
> yet, IMO it would hamper readability (probably in many cases) and it would be
> better to do it inside the function.
> I understand destructuring parameters just as syntactic sugar and I would 
> still
> expect that PhpDocumenter would indicate that my function requires an array.
> Otherwise the same feature would suddenly also be used to declare deep
> structured data structures and at this point I am not so sure whether auto
> conversion of keys play well together with strict mode. It would certainly be
> interesting from a type safety point of view that one can define very complex
> data structures and let PHP do the work for verification. Yet, it also opens a
> door to very ugly code (well... which also exists without the feature) --
> sorry, drifting away from the topic. 
> 
> Some other points crossing my mind
> - how well does the feature interact with typed arrays (if they should be
> introduced at some point)?
> - how well does it interact with structural types (if they should be 
> introduced
> at some point)?
> 
> And now some points to the RFC:
> - I like the RFC in general
> - I am not really a fan of the naming "list" in general but I think it is
> appropriate to reuse the same syntax for this task.
> - one thing I am missing in the RFC is error handling. What happens if a key 
> is
> not found? And there are surely other questions. I think you should include a
> section about error handling in the RFC.
> - I guess mixing number keys with string keys is possible, right?
> - are placeholders (something like list(_ , $a, _) = [1,2,3])  in your 
> pipeline
> or do you think they make no sense in PHP?
> - already an idea how it would interact with pattern matching? 
> 
> Cheers,
> Robert
> 
> 
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] WIKI: phpng-upgrading

[Nikita Popov]

On Wed, Jan 20, 2016 at 10:55 PM, Yasuo Ohgaki  wrote:

> Hi ZendEngine developers,
>
> I'm not sure if the wiki page is maintained, but I noticed few errors.
>
> https://wiki.php.net/phpng-upgrading#strings
> has following example.
>
> - ZVAL_STRING(zv, str, 1);
> + ZVAL_STRING(zv, str);
>
> - ZVAL_STRINGL(zv, str, len, 1);
> + ZVAL_STRINGL(zv, str, len);
>
> - ZVAL_STRING(zv, str, 0);
> + ZVAL_STRING(zv, str);
> + efree(str);
>
> - ZVAL_STRINGL(zv, str, len, 0);
> + ZVAL_STRINGL(zv, str, len);
> + efree(str);
>
> Since PHP5 has following definition for ZVAL_STRING*()
>
> #define ZVAL_STRING(z, s, duplicate) do {\
> const char *__s=(s);\
> zval *__z = (z);\
> Z_STRLEN_P(__z) = strlen(__s);\
> Z_STRVAL_P(__z) = (duplicate?estrndup(__s,
> Z_STRLEN_P(__z)):(char*)__s);\
> Z_TYPE_P(__z) = IS_STRING;\
> } while (0)
>
> the example's 0 and 1 are flipped, efree() locations are wrong.
>

These examples are correct. In PHP 7 ZVAL_STRING always duplicates, which
is what the 1 parameter used to signify.


> In https://wiki.php.net/phpng-upgrading#zend_string_api ,
> it says
>
> zend_string_init(char *val, int len, int persistent)
>
> Current definition is
>
> zend_string_init(char *val, size_t len, int persistent)
>
> Should I update the doc or is the doc is maintained
> elsewhere?
>

I've fixed this. But yes, you should update the doc, it's not maintained
elsewhere.

Thanks,
Nikita

RE: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Zeev Suraski]

> -Original Message-
> From: Derick Rethans [mailto:der...@derickrethans.nl]
> Sent: Wednesday, January 20, 2016 9:04 PM
> To: PHP Developers Mailing List 
> Subject: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> 
> Hi,
> 
> I've decided to re-propose the CoC RFC. There are many reasons for it, but
> there are a few points I want to make.
> 

I want to point three key concerns that are unrelated to the contents of the 
updated RFC before addressing the RFC itself (in short).  Note that I'm not 
blaming or otherwise holding you in any negative light in any way, but rather, 
stating my opinion on the context of the RFC.

First, on process.
I continue to hold that this proposal does not belong under the umbrella of the 
RFC process, given that the RFC process was never meant to deal with such 
cases.  It was meant to deal with technical and administrative items.  I have 
no idea whether or not this can win 2/3 of the votes, but regardless, it should 
pass a much higher bar for acceptance as an essential from-scratch 
'constitution' for the PHP project.  Having a controversial constitution from 
the get go is unacceptable IMHO.

Second, on drama.
I think that the situation where someone withdraws an RFC and another person 
all-too-expectedly takes over needs to stop.  It's one thing to turn to someone 
else and have them lead from now.  It's an entirely different thing to withdraw 
and have someone else take over.  I think that if someone withdraws an RFC (as 
opposed to amending it or adding additional co-authors) - it should have the 
same ramifications as a failed vote.  Withdrawing an RFC should not be a 
dramatic instrument.  Yes, I realize the Voting RFC doesn't state that.  I'm 
stating my opinion.

Third, on undue pressure.
Certain people have either implied or outright said that not having a CoC will 
make them reconsider actively contributing to PHP.  This is undue pressure 
IMHO, avoiding the use of bigger words.

I also want to quickly address the essence of the updated RFC in short, and in 
particular, it's stated goal:

> I strongly believe that a Code of Conduct is required. The amount of toxic
> behaviour on this list is in my opinion unacceptable. It drives people away, 
> it
> certainly did. It is also one of the reasons I am not nearly as active as I 
> used to
> be.

Much of what I wrote in my message to Anthony, that can be titled "What could 
possibly go wrong?", still holds with the updated draft (the message is 
available here:  www.mail-archive.com/internals@lists.php.net/msg82913.html).

There's one very notable exception - there is no ambiguity in any way about 
what you're trying to address - which is fix 'toxic internals'.  Notably, this 
is a substantial shift (and arguably a 180 degrees turn) from what Anthony said 
this RFC is supposed to address:

>> "There are two prime reasons people may avoid internals (at least related to 
>> this discussion).
>> 1. Don't want to deal with the aggressive tone of the list 2. Don't want to 
>> expose themselves to targeted aggression/negativity
>> The first is not in scope of this RFC. We may or we may not want to take 
>> steps in the future to "fix" that, but that's not in scope here."

For me, it validates that my worries about the widespread confusion were indeed 
completely justified.  But much worse, it means that with the author's stated 
goal of this RFC addressing the 'Toxic Internals' issue, the risks associated 
with this RFC are no longer theoretical.  They're real, and we'd be slipping 
down that slippery slope sooner rather than later.

I'm not going to repeat arguments I've made half a dozen times as to why having 
a judicial system must be avoided, and why we must deal exclusively with 
desired behaviors and not the 'exception handling' of bad behaviors.  I made my 
case in the best possible way I can and people who are interested in it can 
read it in my previous replies on the topic.  Equally important - many others 
expressed similar views.  Thus far, the only response is a laconic 'without 
penalties it's useless', even though we've brought numerous supporting 
arguments as why this is simply not true.

I will repeat that I'm very much in favor of a CoC that includes our positive 
core values, and that includes a mediation team in case people are feeling 
offended and that can intervene also w/o complaint - but that does not have any 
sort of special powers - but is instead exclusively based on good will of all 
parties.  Even if certain people don't think that's good enough, I don't 
believe that anybody would argue that it's BAD - the way many think the current 
CoC proposal is.  This is precisely why this is the right place to start.

Thanks,

Zeev

Re: [PHP-DEV] WIKI: phpng-upgrading

[Yasuo Ohgaki]

Hi Sean,

On Thu, Jan 21, 2016 at 7:07 AM, Sean DuBois  wrote:
>
> I tried to get access to that page as well, but didn't have any luck
> would you mind adding the zend_parse_paramaters changes?
>
> 'l' went from 'long' -> 'zend_long' and 's' went from 'int' -> 'size_t'.
>
> So many extensions have been ported without this in mind, and it bites
> in really nasty hard to reproduce runtime ways.

Good point.
zend_parse_parameters() is using "size_t" for string length, since
zend_string uses size_t for it.

struct _zend_string {
zend_refcounted_h gc;
zend_ulongh;/* hash value */
size_tlen;
char  val[1];
};

AFAIK, PHP7 repo's function parameters are changed to size_t.
This should be described in upgrading doc for 3rd party module
developers.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Stanislav Malyshev]

Hi!

> First, on process.

Tangentially related, by pure coincidence I was given today a link to an
IETF RFC describing their view on consensus:

https://tools.ietf.org/html/rfc7282

While their procedures are substantially different from ours, and for a
good reason, I think learning from their experience and their take on
what consensus means and how one would get there would be educational. I
know for me it was.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Pádraic Brady]

Hi,

Up front, I agree the objective of the COC needs to be clearly stated.
There is confusion, whether it's here or externally by observers, as
to whether this is intended to fix mailing list toxicity (I assume,
for now, not) or intended to state the projects intentions should
there be a complaint concerning conduct as specifically listed in the
COC text per the RFC. It serves neither side when this confusion gets
muddled into argument for, against or in-between.

On 20 January 2016 at 22:14, Zeev Suraski  wrote:
> I'm not going to repeat arguments I've made half a dozen times as to why 
> having a judicial system must be avoided, and why we must deal exclusively 
> with desired behaviors and not the 'exception handling' of bad behaviors.  I 
> made my case in the best possible way I can and people who are interested in 
> it can read it in my previous replies on the topic.  Equally important - many 
> others expressed similar views.  Thus far, the only response is a laconic 
> 'without penalties it's useless', even though we've brought numerous 
> supporting arguments as why this is simply not true.
>
> I will repeat that I'm very much in favor of a CoC that includes our positive 
> core values, and that includes a mediation team in case people are feeling 
> offended and that can intervene also w/o complaint - but that does not have 
> any sort of special powers - but is instead exclusively based on good will of 
> all parties.  Even if certain people don't think that's good enough, I don't 
> believe that anybody would argue that it's BAD - the way many think the 
> current CoC proposal is.  This is precisely why this is the right place to 
> start.
>
> Thanks,
>
> Zeev

At a basic level, what exactly is a code of conduct where the only
consequence is mediation, where both parties are assumed to have good
will, and where the outcome is ??. That's the a problem from
my perspective. What is the outcome? Does mediation continue
indefinitely without results? While the mediation is ongoing for the
long haul, will be there be any remediation set to protect a
theoretical victim? What is Plan B? Part of the COC is to explicitly
limit ad-hoc reactions should things go completely down the gutter by
defining something upfront. By extension, any uncertainty of what
would happen should Person A complain may act as a deterrent to making
such a complaint. It could be anticipated that long drawn out
procedures with an unknown ending are in and of themselves stressful
(and to both parties to boot).

Sincere apologies if this is covered elsewhere.

Paddy

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[Andrea Faulds]

Hi Zeev,

Zeev Suraski wrote:

I want to point three key concerns that are unrelated to the contents of the 
updated RFC before addressing the RFC itself (in short).  Note that I'm not 
blaming or otherwise holding you in any negative light in any way, but rather, 
stating my opinion on the context of the RFC.

First, on process.
I continue to hold that this proposal does not belong under the umbrella of the 
RFC process, given that the RFC process was never meant to deal with such 
cases.  It was meant to deal with technical and administrative items.  I have 
no idea whether or not this can win 2/3 of the votes, but regardless, it should 
pass a much higher bar for acceptance as an essential from-scratch 
'constitution' for the PHP project.  Having a controversial constitution from 
the get go is unacceptable IMHO.


I wouldn't say the idea of a code of conduct is really a constitution 
per se (it's not setting down the foundation and goals of the PHP 
project, merely rules for misconduct), it's more like an administrative 
document. That being said, you may have a point with it not being what 
RFCs were really intended for. But we don't really have an alternative 
process for this currently established, so an RFC is the best we can do.



Second, on drama.
I think that the situation where someone withdraws an RFC and another person 
all-too-expectedly takes over needs to stop.  It's one thing to turn to someone 
else and have them lead from now.  It's an entirely different thing to withdraw 
and have someone else take over.  I think that if someone withdraws an RFC (as 
opposed to amending it or adding additional co-authors) - it should have the 
same ramifications as a failed vote.  Withdrawing an RFC should not be a 
dramatic instrument.  Yes, I realize the Voting RFC doesn't state that.  I'm 
stating my opinion.


We work in the open and follow the spirit of open-source. Anyone can 
copy and modify any other RFC if they so please. If we don't allow 
people to resurrect other RFCs, then it gives the original author more 
control than perhaps they should have. Consider that during the Scalar 
Type Declarations dicussions, you revived an earlier version of my RFC, 
because you wanted to keep that approach alive. Likewise, when I left 
due to personal issues, Anthony revived my RFC in a new form. Sara was 
also going to revive my RFC if I remember rightly. Were we all wrong?


RFC revival is essentially like forking, and that's always allowed in 
open-source.



Third, on undue pressure.
Certain people have either implied or outright said that not having a CoC will 
make them reconsider actively contributing to PHP.  This is undue pressure 
IMHO, avoiding the use of bigger words.


It might leave others feeling pressured, but it's not their fault if 
those contributors feel unsafe without a code of conduct. Nor is the 
flip-side true: a certain person said they fear getting in trouble for 
their political views if the CoC passes, and if they wanted to leave as 
a result, so be it. Nobody is under any obligation to contribute to PHP, 
they can freely choose not to contribute if they wish, and that is their 
right.


I think it would be worse if you were not allowed to make such 
statements. It's better that people be aware of consequences than be 
surprised later.



I also want to quickly address the essence of the updated RFC in short, and in 
particular, it's stated goal:


I strongly believe that a Code of Conduct is required. The amount of toxic
behaviour on this list is in my opinion unacceptable. It drives people away, it
certainly did. It is also one of the reasons I am not nearly as active as I 
used to
be.


Much of what I wrote in my message to Anthony, that can be titled "What could 
possibly go wrong?", still holds with the updated draft (the message is available 
here:  www.mail-archive.com/internals@lists.php.net/msg82913.html).

There's one very notable exception - there is no ambiguity in any way about 
what you're trying to address - which is fix 'toxic internals'.  Notably, this 
is a substantial shift (and arguably a 180 degrees turn) from what Anthony said 
this RFC is supposed to address:


"There are two prime reasons people may avoid internals (at least related to 
this discussion).
1. Don't want to deal with the aggressive tone of the list 2. Don't want to 
expose themselves to targeted aggression/negativity
The first is not in scope of this RFC. We may or we may not want to take steps in the future 
to "fix" that, but that's not in scope here."


For me, it validates that my worries about the widespread confusion were indeed 
completely justified.  But much worse, it means that with the author's stated 
goal of this RFC addressing the 'Toxic Internals' issue, the risks associated 
with this RFC are no longer theoretical.  They're real, and we'd be slipping 
down that slippery slope sooner rather than later.


Personally, I don't see how expanding from covering serious 

Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility

[Michael Wallner]

On 08/12/15 10:56, Dmitry Stogov wrote:
> Hi Sean,
> 
> The PR has been merged into master.
> Please update the RFC accordingly.
> Thanks to Nikita and Xinchen for code review and suggestions.
>


This patch seems to cause problems for me with registering constants on
internal interfaces; see bug #71413 https://bugs.php.net/71413


-- 
Regards,
Mike

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Pedro Cordeiro]

The bottom line is that the only requisite for contributors is
professionalism. People should keep non-work related issues to themselves
inside the workplace, as well as they should be respectful to each other no
matter what.

However, if someone is professional and has never posted off-topic opinions
or discriminated someone in the workplace (or within the boundaries of the
project, github, mailing lists, forums, etc), the project mantainers have
no business snooping through their personal social accounts to see if they
are against gay marriage.

Also, 'offensive' is always subjective. On a more moderate example,
supporting Edward Snowden might be offensive to someone who lost a child in
a terrorist attack and that thinks the government has the right to protect
the people by using any means necessary.

2016-01-19 16:17 GMT-02:00 Arvids Godjuks :

> 2016-01-19 20:03 GMT+02:00 Arvids Godjuks :
>
> > Hello to everyone.
> >
> > The Draft states:
> >
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> >
> > TL;DR: Just no.
> >
> > Long version:
> >
> > What is the definition of "representing project or it's community". If I
> > make a single commit that get's accepted to the project, and then I say
> > something 3 years down the line about the project (in this case PHP), do
> I
> > still represent the project or it's community? Or I have added to
> > conversations on this mailing list for years now, does that mean i'm a
> > contributor now and I'm responsible for anything I say about the project
> or
> > it's community going forward?
> > And what is PHP community? It's not like PHP community is a tight group -
> > it's huge, with tens of millions of people at least all over the world.
> >
> > This is especially a worry for me, because I run a PHP conference, and
> > people come to speak to it. I do not want to deal with people dictating
> me
> > "I want you to pull this person because his views on blah are bla bla bla
> > and that is unacceptable". I do not care about the persons views on any
> > subject, unless:
> > a). It breakes the laws of my country (hate speech, harassment, gender
> > discrimination and all that stuff that is actually covered by laws).
> > b). The person goes into issues, that are not the topic of the
> conference.
> > c). Behaves in a way, that is not acceptable in the society (personal
> > insults, unacceptable language, and so on).
> > And what if I actually agree with that person in my own views? And why
> > someone thinks he has the right to dictate what views are acceptable and
> > witch are not? (i'm not talking about issues, that are universally
> > unacceptable to talk about).
> >
> > Regarding c) - you should remember, that in different parts of the world
> > the social norms vary - from slightly to moderate between western
> cultures,
> > to quite a lot for asian/latin american/african/etc. . Every country is
> > different, especially those, that are quite far apart. That means that
> > people will be doing things, that are totally acceptable and are the norm
> > in their country, when they are preforming at the local conference, but
> > will probably trigger a storm somewhere else, and that may result in
> things
> > going horribly wrong.
> >
> > So, as far as my personal opinion goes, CoC has to apply only to project
> > spaces in full, and for the public spaces it has to have a clear
> > definition, when CoC applies. I really do not want to see situation like
> > they happened in other projects, when a person can be booted off the
> > project just because he does not support some trending new thing in
> social
> > areas (pick any social issue in recent 20 years), but is absolutely a
> model
> > member of the project. This is a tech project, not a social gathering to
> > impose social trends and rallying support for social issues.
> >
> > * Any personal opinions on any subject not directly related to the
> project
> > itself should be out of the scope of CoC. This has to be written in from
> > the start, otherwise people will find a way to exploit it to generate
> > controversy and drama on the subjects that are not related to the PHP
> > project.
> > * CoC should clearly state that it is designed only to handle the conduct
> > in project channels and official representation of the project. The
> > representation part should be defined.
> > * Any requests coming in on the issues, that are not directly related to
> > the PHP project itself, should be outright rejected. In case of abuse
> > (trying to re-open the issues) the access should be restricted if that's
> > technically possible.
> >
> > Otherwise, as history shows, the rules are abused sooner or later. And
> the
> > amount of controversy we have around PHP every minor and major release,
> > that's a given.
> >
> > Above written is a rough thought list on the