[PHP-DEV] Re: [RFC Discussion] Precise Session Management

[Yasuo Ohgaki]

Hi all,

On Tue, Jan 26, 2016 at 4:01 PM, Yasuo Ohgaki  wrote:
> Since the function only allows chars used by ID, I would like to add "_" a
> valid char. "_" should be very safe char.

I think about possible attack/misuse scenario a little more and come
up with following.

"_" is wild card char of SQL's LIKE query. Although, it should be rare to use
session ID string for LIKE query, one may do

SELECT * FROM my_sess_table WHERE sess_id LIKE '$id';
where $id is '__'.

This may allow to fetch all session IDs in DB. Users will likely write
such query with prefixed session ID, so I don't think allowing "_" is
not good idea after all. I'll keep as it is now, but if you have good
option. Please let me know.

Regards,

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

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

[PHP-DEV] Re: [RFC Discussion] Precise Session Management

[Yasuo Ohgaki]

On Tue, Jan 26, 2016 at 4:01 PM, Yasuo Ohgaki  wrote:
> Currently, the use of "PHPAPI php_session_valid_chars()" is up to save 
> handler,
> but it should be checked always by session module. Since the function
> only allows

Oops, sorry

s/PHPAPI php_session_valid_chars()/PHPAPI php_session_valid_key()/


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

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

[PHP-DEV] Re: [RFC Discussion] Precise Session Management

[Yasuo Ohgaki]

Hi all,

On Tue, Jan 26, 2016 at 11:22 AM, Yasuo Ohgaki  wrote:
> On Fri, Jan 22, 2016 at 10:32 AM, Yasuo Ohgaki  wrote:
>> On Fri, Jan 22, 2016 at 10:19 AM, Yasuo Ohgaki  wrote:
>>>
>>> https://github.com/php/php-src/pull/1734
>>>
>>> Few things are missing still, but it's good enough to review basic features.
>>
>> Please note that if you execute run-tests.php with this patch,
>> it causes failures on other branches/versions' session tests.
>>
>> To remove these test errors, you can do
>>
>> rm -f /tmp/sess_*
>> rm -f /tmp/u_sess*
>>
>> This issue will be fixed by the time when patch is completed.
>
> Other than test dependency issue, all issues and proposals are
> fixed/implemented. Test dependency will be fixed before merge.
>
> https://wiki.php.net/rfc/precise_session_management
> https://github.com/php/php-src/pull/1734
>
> Session will be more reliable and secure with this.
> Please review and comment. If there is no issues, I'll start
> vote shortly.

I didn't pay attention that current session_id() allows any chars for session ID
while session module and save handlers explicitly disallow characters for
security reasons. e.g. Session module silently removes HTML special chars,
files save handler does not allow PATH special chars.
Current situation is not good at all.

Since this RFC is about preciseness of session management, I would like to
change session_id() validates against default allowed chars as follows.
(As well as enabling already written session_create_id() function)
This patch is against the PR.

Currently, the use of "PHPAPI php_session_valid_chars()" is up to save handler,
but it should be checked always by session module. Since the function
only allows
chars used by ID, I would like to add "_" a valid char. "_" should be
very safe char.


These changes for session ID would be the largest BC of this RFC.
Any comments for this change?


diff --git a/ext/session/session.c b/ext/session/session.c
index 7b3203a..fdc6a91 100644
--- a/ext/session/session.c
+++ b/ext/session/session.c
@@ -566,7 +566,7 @@ PHPAPI int php_session_valid_key(const char *key) /* {{{ */

 /* Somewhat arbitrary length limit here, but should be way more than
anyone needs and avoids file-level warnings later on if we
exceed MAX_PATH */
-if (len == 0 || len > 128) {
+if (len == 0 || len > PHP_SESSION_KEY_MAX_LEN) {
 ret = FAILURE;
 }

@@ -2460,31 +2460,35 @@ static PHP_FUNCTION(session_save_path)
Return the current session id. If newid is given, the session id
is replaced with newid */
 static PHP_FUNCTION(session_id)
 {
-zend_string *name = NULL;
+zend_string *id = NULL;
 int argc = ZEND_NUM_ARGS();

-if (zend_parse_parameters(argc, "|S", &name) == FAILURE) {
+if (zend_parse_parameters(argc, "|S", &id) == FAILURE) {
 return;
 }

 if (PS(id)) {
-/* keep compatibility for "\0" characters ???
- * see: ext/session/tests/session_id_error3.phpt */
-size_t len = strlen(ZSTR_VAL(PS(id)));
-if (UNEXPECTED(len != ZSTR_LEN(PS(id {
-RETVAL_NEW_STR(zend_string_init(ZSTR_VAL(PS(id)), len, 0));
-} else {
-RETVAL_STR_COPY(PS(id));
-}
+RETVAL_STR_COPY(PS(id));
 } else {
 RETVAL_EMPTY_STRING();
 }

-if (name) {
+if (id) {
 if (PS(id)) {
 zend_string_release(PS(id));
 }
-PS(id) = zend_string_copy(name);
+if (php_session_valid_key(ZSTR_VAL(id)) == FAILURE) {
+zend_string *new_id;
+/* Set random ID for security reason. */
+php_error_docref(NULL, E_WARNING,
+ "Session ID cannot exceed session max length %d "
+ "and/or contain special characters. Only
aphanumeric, ',', '-' are allowed "
+ "Random session ID is set",
+ PHP_SESSION_KEY_MAX_LEN);
+PS(id) = php_session_create_id(NULL);
+} else {
+PS(id) = zend_string_copy(id);
+}
 }
 }
 /* }}} */
@@ -2519,7 +2523,6 @@ static PHP_FUNCTION(session_regenerate_id)

 /* {{{ proto void session_create_id([string prefix])
Generate new session ID. Intended for user save handlers. */
-#if 0
 /* This is not used yet */
 static PHP_FUNCTION(session_create_id)
 {
@@ -2531,34 +2534,34 @@ static PHP_FUNCTION(session_create_id)
 }

 if (prefix && ZSTR_LEN(prefix)) {
-if (php_session_valid_key(ZSTR_VAL(prefix)) == FAILURE) {
-/* E_ERROR raised for security reason. */
-php_error_docref(NULL, E_WARNING, "Prefix cannot contain
special characters. Only aphanumeric, ',', '-' are allowed");
-RETURN_FALSE;
+if (php_session_valid_key(ZSTR_VAL(prefix)) == FAILURE
+|| ZSTR_LEN(prefix) > PHP_SESSION_KEY_MAX_LEN/2) {
+/* Do not use prefix for security reason. */
+php_error_docref(NULL, E_WARNING,
+   

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

[Yasuo Ohgaki]

Hi Umberto,

On Fri, Jan 22, 2016 at 9:49 PM, Umberto Salsi  wrote:
> thank you very much for the reply, I now start understanding better what
> happen and why currently i/o cannot be handled in user's space.

You're welcome.
I think you have pointed out important missing parts in PHP.

> Rather than an array of error, which might be quite expensive to handle,
> why not a simple "char * lasterror" field added to the stream struct,
> normally set to NULL, where a description of the last error occurred may
> be stored? The high-level functions, that is PHP fopen, fread, fwrite,
> fflush, fseek, fclose, may then check that string and, if set, trigger
> E_WARNING with a meaningful message after having reset that string back
> to NULL again. Many C libraries already provide such error strings,
> starting from the same C strerror().

Pgsql's "notice" logging is implemented this way at first. Then I changed
it to array of notices recently.  (Notice is raised during
transaction, for example)

It's very difficult or impossible to detect where something wrong happened
if there is only the last error. That's the reason why pgsql module is changed
to have array of notices.

The same would happen in streams, so it's better to store all errors during
operation. Zend hash is extremely fast and good enough for logging errors,
so we don't have to worry overheads.

>
> The same should then be done with the filters, which currently only may
> return PSFS_ERR_FATAL, but might have their "char * lasterror" string
> too with the same purpose. Knowing the exact reason of the failure is
> essential to distinguish, for example, a dead disk drive or corrupted file
> system, from a bare file mistakenly opened with the wrong decompressor
> or a file which was badly encoded.

I agree.

>
> Then all the specific stream and filter implementations can be adjusted
> to set that error string; for those still not fixed that string remains
> NULL and fopen, ferror, etc. will not report the error just as they do
> today, and will be fixed later step by step.

Agree here, too.
Someone have to volunteer for this. It's not difficult for people on this list.
I have too many backlogs for PHP project, so I hope someone volunteers
for this.

Regards,

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

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

[PHP-DEV] Re: [RFC Discussion] Precise Session Management

[Yasuo Ohgaki]

Hi all,

On Fri, Jan 22, 2016 at 10:32 AM, Yasuo Ohgaki  wrote:
> On Fri, Jan 22, 2016 at 10:19 AM, Yasuo Ohgaki  wrote:
>>
>> https://github.com/php/php-src/pull/1734
>>
>> Few things are missing still, but it's good enough to review basic features.
>
> Please note that if you execute run-tests.php with this patch,
> it causes failures on other branches/versions' session tests.
>
> To remove these test errors, you can do
>
> rm -f /tmp/sess_*
> rm -f /tmp/u_sess*
>
> This issue will be fixed by the time when patch is completed.

Other than test dependency issue, all issues and proposals are
fixed/implemented. Test dependency will be fixed before merge.

https://wiki.php.net/rfc/precise_session_management
https://github.com/php/php-src/pull/1734

Session will be more reliable and secure with this.
Please review and comment. If there is no issues, I'll start
vote shortly.

Thank you.

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

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

Re: [PHP-DEV] RE: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no problem 5.5 or 5.3

[Christopher Jones]

Not sure if this helps, but perhaps something like this:

# gmake Makefile fragment to clean a file of its carriage returns.
# Carriage returns drive the Studio compiler crazy.
cleancr = $(GSED) -i -e 's/\r//g' $(1) ;

Chris

On 26/01/2016 3:05 AM, Ross, Christine wrote:

Hi

Thank you for getting back to me.  I installed 5.6.17 that I downloaded from 
php.net.  I had previously tried 5.6.10 with the same results.  I'm running 
v2.5 of bison and v0.13.5 of re2c.   When I was trying to debug this I 
installed re2c but it didn't help.   I could install a later version of bison 
but PHP compiled with GCC4 without issue and I think it checks for bison on 
that compile.Everything in this web application and the database is using 
Sun CC 12.3 so I hate to change it.

I realized I didn't reply to the list so I am sending this again and adding the 
email address for the list.

Thanks for your suggestions.


-Original Message-
From: Lior Kaplan [mailto:lio...@zend.com]
Sent: Monday, January 25, 2016 5:26 AM
To: Ross, Christine; internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: Re: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Please try the sources available from the website (e.g. 5.6.17), these are 
already have some files pre-generated.

Regradless, which versions of re2c/bison do you have on that system?

Kaplan


From: Ross, Christine 
Sent: Saturday, January 23, 2016 11:29 PM
To: internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: [PHP-DEV] compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Hello.

It was suggested I email this to this address.  I hope someone can help. I had 
no problems compiling php 5.3.# and 5.5.# on Sparc solaris 10 with Sun CC 12.3, 
but 5.6.# fails with the error below. GCC works but my whole application and 
environment is built with Sun CC. This is where it fails. I even tried adding 
/usr/sfw to the paths but no change.  I have received responses from others 
with the same issue.
Any help would be appreciated.



Lots of white space character errors before it fails on line 70. I saw 
something about flex and re2c so I installed re2c, and it didn't help. I tried 
without opcache, no help.

"Zend/zend_language_scanner.l", line 66: warning: invalid white space character in directive "Zend/zend_language_scanner.l", line 67: 
warning: invalid white space character in directive "Zend/zend_language_scanner.l", line 68: warning: invalid white space character in directive 
"Zend/zend_language_scanner.l", line 69: warning: invalid white space character in directive "Zend/zend_language_scanner.l", line 70: 
warning: function prototype parameters must have types "Zend/zend_language_scanner.l", line 70: warning: old-style declaration or incorrect type for: 
SCNG "Zend/zend_language_scanner.l", line 70: cannot initialize function: SCNG "Zend/zend_language_scanner.l", line 70: undefined symbol: x

#!/bin/sh
#
# Configure PHP
#
PATH=/usr/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/sbin:/usr/dt/bin;
 export PATH LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/ssl/lib; 
export LD_LIBRARY_PATH LD_RUN_PATH=/usr/local/ssl/lib:/usr/local/lib; export 
LD_RUN_PATH # env CC=cc CXX=CC \ ../configure \ 
--with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=mysqlnd \ --with-pear \ 
--with-libxml-dir=/usr \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ 
--enable-mbstring \ --with-curl \ --with-gd \ --with-jpeg-dir=/usr/lib \ 
--enable-soap \ --with-openssl=/usr/local/ssl \ --enable-zip \ 
--with-iconv=/opt/local \ --enable-opcache

#!/end
#



--
http://twitter.com/ghrd

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

Re: [PHP-DEV] PHP 7.0.3 RC1 is available for testing - **** BC break ***

[Yasuo Ohgaki]

Hi Remi and all,

On Fri, Jan 22, 2016 at 1:20 AM, Remi Collet  wrote:
> Fedora detected a BC break in 5.6.18RC1 and 7.0.3RC1 related to
> session management.
>
> This update breaks:
>
> Horde_SessionHandler (2.2.6) and symfony (2.7.9)

Thank you for notifying issue.
Remi provided reproduceble phpt for this test failure and
found out the cause of test failure. I really appreciate your help!

Anyway, the cause was bug fix for "session_start() returns
TRUE even when failures". Details for this specific case is following.

Newer session cache limiter has php_session_abort()

static int php_session_cache_limiter(TSRMLS_D) /* {{{ */
{
php_session_cache_limiter_t *lim;

if (PS(cache_limiter)[0] == '\0') return 0;
if (PS(session_status) != php_session_active) return -1;

if (SG(headers_sent)) {
const char *output_start_filename =
php_output_get_start_filename(TSRMLS_C);
int output_start_lineno = php_output_get_start_lineno(TSRMLS_C);

php_session_abort(TSRMLS_C);   << This is the cause
if (output_start_filename) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot send
session cache limiter - headers already sent (output started at
%s:%d)", output_start_filename, output_start_lineno);
} else {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Cannot send
session cache limiter - headers already sent");
}
return -2;
}

This is added because when session cannot be started, then it should fail.
This fix is related to https://bugs.php.net/bug.php?id=71243
The php_session_abort() is not directly related to this bug, but this (and
other fixes) is added because session_start() returns TRUE even when it fails/
should fail.

Note: PHP 5.6's session_start() return value fix is not perfect to keep
save handler compatibility which is a big one. PHP7 should return FALSE
for session_start() failures always by the fix.

Fixing the broken test should be just removing the php_session_abort() from
php_session_cache_limiter().

The reason why it aborts is because it does not make sense to create and/or
write session data even when client does not get the session ID.
Note: session ID cookie is sent only when it is needed. i.e. New session.

I think it does not matter much for session module & users if we remove
the php_session_abort() or not. PHP 5.6's session_start() returns TRUE for
session read error which is fatal, anyway. Being strict for this case does
not worth much.

Whichever is perfectly OK to me for PHP 5.6. For PHP 7.0, I would
like to keep stricter behavior, but do not care much.

How we handle this is up to release managers, since this fix is valid one
even if it broke test on failure case.

Regards,

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

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

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

[lp_benchmark_robot]

Results for project PHP master, build date 2016-01-25 06:30:37+02:00
commit: 319e828
previous commit:af255c6
revision date:  2016-01-24 23:04:15+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.19%  0.40%  
  6.67%
:-|   Drupal 7.36 cgi -T1  0.25%  0.11%  0.06%  
  4.76%
:-|   MediaWiki 1.23.9 cgi -T5000  0.24%  0.03%  0.41%  
  3.30%
:-|   bench.php cgi -T100  0.04% -0.07%  0.55%  
  6.48%
:-|  micro_bench.php cgi -T10  0.02% -0.66% -0.21%  
  4.36%
:-|  mandelbrot.php cgi -T100  0.01%  0.83%-11.60%  
 -1.21%
---
* 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-25/

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] RE: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no problem 5.5 or 5.3

[Ross, Christine]

Hi

Thank you for getting back to me.  I installed 5.6.17 that I downloaded from 
php.net.  I had previously tried 5.6.10 with the same results.  I'm running 
v2.5 of bison and v0.13.5 of re2c.   When I was trying to debug this I 
installed re2c but it didn't help.   I could install a later version of bison 
but PHP compiled with GCC4 without issue and I think it checks for bison on 
that compile.Everything in this web application and the database is using 
Sun CC 12.3 so I hate to change it.

I realized I didn't reply to the list so I am sending this again and adding the 
email address for the list.

Thanks for your suggestions.
 

-Original Message-
From: Lior Kaplan [mailto:lio...@zend.com] 
Sent: Monday, January 25, 2016 5:26 AM
To: Ross, Christine; internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: Re: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Please try the sources available from the website (e.g. 5.6.17), these are 
already have some files pre-generated.

Regradless, which versions of re2c/bison do you have on that system?

Kaplan


From: Ross, Christine 
Sent: Saturday, January 23, 2016 11:29 PM
To: internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: [PHP-DEV] compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Hello.

It was suggested I email this to this address.  I hope someone can help. I had 
no problems compiling php 5.3.# and 5.5.# on Sparc solaris 10 with Sun CC 12.3, 
but 5.6.# fails with the error below. GCC works but my whole application and 
environment is built with Sun CC. This is where it fails. I even tried adding 
/usr/sfw to the paths but no change.  I have received responses from others 
with the same issue.
Any help would be appreciated.



Lots of white space character errors before it fails on line 70. I saw 
something about flex and re2c so I installed re2c, and it didn't help. I tried 
without opcache, no help.

"Zend/zend_language_scanner.l", line 66: warning: invalid white space character 
in directive "Zend/zend_language_scanner.l", line 67: warning: invalid white 
space character in directive "Zend/zend_language_scanner.l", line 68: warning: 
invalid white space character in directive "Zend/zend_language_scanner.l", line 
69: warning: invalid white space character in directive 
"Zend/zend_language_scanner.l", line 70: warning: function prototype parameters 
must have types "Zend/zend_language_scanner.l", line 70: warning: old-style 
declaration or incorrect type for: SCNG "Zend/zend_language_scanner.l", line 
70: cannot initialize function: SCNG "Zend/zend_language_scanner.l", line 70: 
undefined symbol: x

#!/bin/sh
#
# Configure PHP
#
PATH=/usr/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/sbin:/usr/dt/bin;
 export PATH LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/ssl/lib; 
export LD_LIBRARY_PATH LD_RUN_PATH=/usr/local/ssl/lib:/usr/local/lib; export 
LD_RUN_PATH # env CC=cc CXX=CC \ ../configure \ 
--with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=mysqlnd \ --with-pear \ 
--with-libxml-dir=/usr \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ 
--enable-mbstring \ --with-curl \ --with-gd \ --with-jpeg-dir=/usr/lib \ 
--enable-soap \ --with-openssl=/usr/local/ssl \ --enable-zip \ 
--with-iconv=/opt/local \ --enable-opcache

#!/end
#

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

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

[Zeev Suraski]

> -Original Message-
> From: Peter Lind [mailto:peter.e.l...@gmail.com]
> Sent: Monday, January 25, 2016 1:47 PM
> To: Zeev Suraski 
> Cc: Dan Ackroyd ; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct
> 
> On 25 January 2016 at 12:43, Zeev Suraski   > wrote:
> 
> 
> 
> 
>   > -Original Message-
>   > From: Dan Ackroyd [mailto:dan...@basereality.com
>  ]
>   > Sent: Monday, January 25, 2016 12:48 AM
>   > To: Stanislav Malyshev   >
>   > Cc: internals@lists.php.net 
>   > Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of
> Conduct
>   >
> 
>   Arguing against an RFC is at least as legitimate as arguing for it;
> Arguably, even more so - given our bias for status quo.
>   Put another word - the assumption (at least on the technical side)
> that the current situation is good, and there needs to be a very robust case
> enjoying widspread support in order to change it.
> 
> 
> 
> 
> Not to nitpick, but if you're biased against status quo, what you need is
> arguments that remove that bias - not arguments that strengthen it.

I'm not talking about any person in particular - but the project as a whole.  
PHP is a very successful and widely used language, so our starting point with 
every discussion (at least technical one) should be that the status quo is not 
only acceptable, it's actually fine.  It doesn't mean we can't do better and 
improve it - but it does mean that the onus of convincing the public that the 
proposal has merit is on the shoulders of the one making it.  An important part 
of that discussion is that people who think the proposal is lacking, 
superfluous or outright bad, should argue their case.

While I'm very much in favor of encouraging people to think how they can 
improve on RFCs instead of just 'shooting them down', sometimes that's not 
possible or practical:
1.  Some ideas are just bad.
2.  Some ideas maybe generally good, but not good enough to be worth adding.
3.  Some people are better at finding what's wrong with a given proposal than 
they are at improving it.  Often times, others (either the original authors or 
others) are motivated to think harder and come up with solutions to those 
issues when they're brought up.

Regardless, I believe Dan was talking about situations where we had 'stalemate' 
- cases in which people on both opposite camps of a given proposal couldn't 
convince the others.  Censoring one of the sides - arguably the opposing side 
in particular (given the inherent assumption above) - is inconceivable.

> Your assumption that the status quo is good is a problem if it is a bias.

Bias may or may not be the correct term here, but yes, I think the status quo 
is good.  PHP is doing very well. 

> It is not
> a good thing, on the contrary, it actively prohibits you from considering
> better alternatives to the status quo.

Not at all, it just means that changes to the status quo must be duly 
scrutinized.  An inherent part of that is trying to poke holes at it, or go as 
much as arguing against it if people think it's bad.
 
Zeev

Re: [PHP-DEV] Re: [RFC] Generalize support of negative string offsets

[François Laupretre]

Hi Andrea,

Le 23/01/2016 22:10, Andrea Faulds a écrit :


Er, ignore what I just said. Negative string offsets are actually
special-cased and always produce an "Unitialized string offset" or
"Invalid string offset" notice. So our current behaviour is in fact
completely useless, not just mostly. :)


Thanks for your comments. Following your suggestion, I just added some 
examples of negative offset usage.


About BC breaks, the RFC just adds support for currently-invalid values. 
In every cases, these values would have generated a notice or a warning, 
and the value would have been considered as zero. So, I consider these 
BC breaks as minor because of error messages. But determining if such BC 
breaks are compatible with a minor release will be the main objective of 
the vote.


Regards

François


--
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

[Zeev Suraski]

That's been in my queue for a while...

> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Thursday, January 21, 2016 6:26 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> 
> Hi,
> 
> > Namely - decision by consensus.  This is absolutely required in a topic as 
> > far-
> reaching as this, which is very clearly outside the scope of the RFC process.
> 
> What do you consider to constitute consensus? Absolute unanimity, or large
> majority support?

I think consensus is comprised of two things:

1. Truly trying to come up with a resolution that is not controversial - i.e., 
where you have either no or virtually no people who think the resolution is 
downright BAD.  Note the difference from thinking that it's not good or 
unhelpful, or people that are indifferent to it - but rather, people thinking 
it's bad.  As long as you have a fair number of people who think the resolution 
is downright bad - it's outside the consensus IMHO - regardless of any 
particular majority bar.  So it's not only the amount of people who are voting 
no, but also their level of opposition to the proposal.  I think the amount of 
people who've expressed strong opposition to the principals laid out by Anthony 
as mandatory for an acceptable CoC (scope of applicability, teeth, etc.) are 
clear indicators for lack of consensus around a controversial proposal.
 
2.  Once you have a proposal  that doesn't have strong opposition - you still 
need an overwhelming majority to ratify it, to make sure people aren't only 
comfortable with the general idea but also with the details.  I think it's 
pretty easy to spot consensus, and most of our decisions win what I would call 
consensus.  Looking again at bit.ly/php7rfcs - I'd say an 85-90% bar would be 
reasonable.
As a flipside example, I suspect we should be able to agree on values and 
mediation principals with a majority that will be well above 90%, and without 
anybody arguing that it would be bad for the project.  There'll probably still 
be people voting against it because they'd think it's not needed, a waste of 
time or whatnot - but you'd be very unlikely to find people actively 
campaigning against it.  That's indicative of consensus.

> My fear here does not come from the PHP mailing list. PHP internals, for all
> its "toxic kindergarten"-ness, is mostly civil. We're not the Linux Kernel
> Mailing List, and I think that's something we can all be proud of. The broader
> PHP community, however, is not always quite so friendly.

I *very* much appreciate your words here.  Although I'm personally not a 
subscriber to the idea that internals is a toxic kindergarten (although it can 
certainly become one at times) - I'm happy you're viewing internals as (mostly) 
civil.

Thanks,

Zeev

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

[Derick Rethans]

Hi,

There was a lot of traffic over the weekend, and several of you have 
provided suggestions and rewordings of several documents through
https://github.com/derickr/php-community-health

I've adopted some, I have declined some (with reasons), and I've left 
some unresolved.

As I wrote in my mail on Friday, I split up the documents in the 
sections:

1. The goal of the documents, and our general values.
   
   Should already be at 
   https://github.com/derickr/php-community-health/blame/master/RFC.rst#L18, 
   but improvements welcome

2. Our contributor guidelines (ie. how to behave on the mailinglists etc)

   Now at 
   
https://github.com/derickr/php-community-health/blob/master/contributor-guidelines.rst

3. The Code of Conduct

   I have changed the text as adopted by Davey in 
   https://github.com/derickr/php-community-health/issues/14
   I realize this is just one change, and I do want to look better at 
   the Go CoC that many of you have mentioned, but that's for *after* we 
   looked at point 2.

4. The Mediation Team
5. Procedures

And I added one: "6. Examples" where we can collect thought experiments 
and clarification that doesn't really fit into any of the others. 
Perhaps the 'Shitty' PR case study would be great in there too (please 
add a PR).

But first things first. 

The first document that I think we can go through quite quickly, 
includes the Collaborative Contributing Guidelines that I wrote before, 
and in the same document includes the Mailinglist Posting Rules and 
Mailing List Rules that we already had written down:

https://github.com/derickr/php-community-health/blob/master/contributor-guidelines.rst

This documents needs editing for duplication, and perhaps we should 
remove 
https://github.com/derickr/php-community-health/blob/master/contributor-guidelines.rst#mailing-list-posting-guidelines
 
in case it's not in scope?

I am going to give it a shot later, but comments and Pull Requests are 
welcome of course.

*Please* leave the text of the Code of Conduct for the next phase.

cheers,
Derick

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

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

[Allan MacGregor]

Hi Stanislav,

I have made a small change to The Pragmatist Code of conduct from 
'behave like an adult to 'you are expected to show others civility and 
courtesy.'


> This one basically can be TLDRed as "behave as an adult". Which is nice
> if we were to agree what it means, but that is in no way automatic, thus
> I am afraid it is not enough :) Assuming good faith is a nice touch
> though, I like it.

That should be cleared, and assuming good faith should be part of the 
CoC no matter which one we choose in the end, having people in the 
project so many diverse background and cultures.


Here is the thing, it might not be enough but is at least what I 
consider a minimal foundation; the way the conversation has approach the 
problem so far is trying to elaborate on every single scenario and how 
to penalize the bad actors on those scenarios.


But if we are to agree into a first version of the PHP CoC then we 
should start with minimum requirements the MVP if you like :D.


Asking people to assume good faith and be civil is in my opinion all we 
can and should ask in my opinion; yes there will be misunderstandings, 
yes there will be bad actors. But when the time comes those scenarios 
can be deal with.


This at it's core is what really bothers me about the Contributors 
Covenant and the whole narrative behind that assumes to worst in people; 
that in my opinion is fundamentally wrong.


Assume the best in people and you will pleasantly surprised, assume the 
worst of them and all your fears will be validated.


Kind Regards,
Allan MacGregor

Stanislav Malyshev wrote:

Hi!


Now, if we are still adamant on coming up with a CoC first I would like
to put forward the following 3 documents as alternatives for the
Contributor Covenant:


[A contribution policy for open source that
works](https://medium.com/@jmaynard/a-contribution-policy-for-open-source-that-works-bfc4600c9d83#.d53666v7u)


This one deals with code contributions, but our discussion is wider. In
fact, we never, as far as I could remember, had code contribution which
was per se controversial. We did have ones that were controversial in
that we disagreed on whether or not that code is doing what we actually
want to do, but the code usually is not a problem.


[The Code of
Merit](https://github.com/rosarior/Code-of-Merit/blob/master/CODE_OF_MERIT.md)


I don't particularly like this approach, it sounds too defensive.


[The Pragmatists Code of
Conduct](https://github.com/amacgregor/Pragmatists-Code-of-Conduct/blob/master/Prag-Code-of-Conduct.md)



This one basically can be TLDRed as "behave as an adult". Which is nice
if we were to agree what it means, but that is in no way automatic, thus
I am afraid it is not enough :) Assuming good faith is a nice touch
though, I like it.


--
Allan MacGregor
coderoncode.com 


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

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

[Peter Lind]

On 25 January 2016 at 12:43, Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: Dan Ackroyd [mailto:dan...@basereality.com]
> > Sent: Monday, January 25, 2016 12:48 AM
> > To: Stanislav Malyshev 
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct
> >
>
> Arguing against an RFC is at least as legitimate as arguing for it;
> Arguably, even more so - given our bias for status quo.
> Put another word - the assumption (at least on the technical side) that
> the current situation is good, and there needs to be a very robust case
> enjoying widspread support in order to change it.
>
>
Not to nitpick, but if you're biased against status quo, what you need is
arguments that remove that bias - not arguments that strengthen it.
Your assumption that the status quo is good is a problem if it is a bias.
It is not a good thing, on the contrary, it actively prohibits you from
considering better alternatives to the status quo.

Regards
Peter



-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

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

[Zeev Suraski]

> -Original Message-
> From: Dan Ackroyd [mailto:dan...@basereality.com]
> Sent: Monday, January 25, 2016 12:48 AM
> To: Stanislav Malyshev 
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct
> 
> A significant number of technical RFC discussions have been less productive
> than they should be, due to people repeatedly sending emails against an
> RFC, that repeat what they have already said, which is not a  productive use
> of anyone's time, and makes people (including
> myself) not want to put forward ideas, or to participate in the discussions.

Arguing against an RFC is at least as legitimate as arguing for it;  Arguably, 
even more so - given our bias for status quo.
Put another word - the assumption (at least on the technical side) that the 
current situation is good, and there needs to be a very robust case enjoying 
widspread support in order to change it.

The nature of divisive RFCs - RFCs that garner strong support from both people 
in favor of them and against them - is that one camp is unable to convince the 
other for prolonged periods of time.  That typically results in both camps 
raising the same reasons, both in favor and against, and 'continuously 
improving' their case.  That's completely legitimate.  It may be tiring - it's 
in fact almost definitely tiring, but there's no way around it - certainly not 
via a CoC that would censor one side or the other from championing what they 
believe in.

The only solution to the divisive RFC syndrome IMHO - that 'immunize' internals 
from having toxic discussions - is to radically bump up the pass threshold for 
RFCs. 

Zeev

Re: [PHP-DEV] alternative valgrind-like support for run-tests along other nice additions

[Yasuo Ohgaki]

Hi Pierre,

On Mon, Jan 25, 2016 at 5:49 PM, Pierre Joye  wrote:
> This is only for Windows but I think it could make sense to provide it
> for other platforms as well, optionally. It can then allow us to
> support other features more easily. I am particularly interested to
> see if we can make some use of the fuzzy testing or use it to test our
> internals APIs (what we cruelly miss now). I did not test the
> performance but they claim to be faster than valgrind.

Although I don't have experience with DrMemory.
Nice idea, for windows developers especially.
+1

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

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

RE: [PHP-DEV] Specific incident in relationship to the proposed Code of Conduct

[Zeev Suraski]

> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Monday, January 25, 2016 1:01 PM
> To: Stanislav Malyshev 
> Cc: Pierre Joye ; PHP internals
> 
> Subject: Re: [PHP-DEV] Specific incident in relationship to the proposed Code
> of Conduct
> 
> On Sat, 23 Jan 2016, Stanislav Malyshev wrote:
> 
> > > I think we should have used temporary bans a bit more to cool down
> > > things. Including to myself along other.
> >
> > Ban is a very dangerous thing, since it excludes people from
> > discussion thus preventing it from reaching a conclusion, achieving
> > consensus and closure, and it also hurts people and labels them ("ah,
> > this guy who was already banned stirs up things again? let's just
> > ignore him, he's obviously a troll").
> 
> But on the flip side, most of us are pretty good sporting trolling anyway

I assume you meant 'spotting' trolling and not sporting them, right? :)

>, and I
> certainly have ignored threads where some people partipated because I
> didn't think it would contribute anything to the discussion. And that means
> you miss out on reasonable comments and opinions too.

I think there's no way around the fact that the amount of traffic on internals 
is simply high for practically anybody that doesn't have internals as their 
full time job.  I personally think trolling is a very small part of it, a part 
that can easily be resolved by 'muting' people that you think are trolling.

As I said in what seems like ages ago, I don't think that internals is toxic - 
certainly not as a rule.  It can certainly *become* toxic in certain 
situations, but on average, I think most of our discussions are on topic.  My 
key challenge with them is simply that there's just too many of them, and too 
much detail in each.  So I pick the ones I actively participate in very 
selectively.  I don't expect a Values document or a CoC to change that.

While in our current quest for Project Values there's no real need to define a 
problem, I think that as the discussion evolves, it would be important to bring 
up specific discussions people think went wrong - but not only point them out, 
but also discuss what we envision should have been done differently had 
Values/CoC/mediation been in place.

> Tthe balance needs to be found as to what's more important: seeing all good
> discussions and comments and inconvieniencing a persistent troll, or drawing
> out reasonable comments manually because of an issue being
> inconvienienced by a troll. I don't know the answer. A balance is important,
> and *perhaps* an option is to do allow for short term (in the order of days)
> "timeout periods" — in case the "please cool down"
> message is repeatly ignored.

I didn't fully understand what you're saying here, but I do think that 'cool 
down periods' are problematic, unless they would be enforced on a given topic, 
as opposed to specific individuals.

One unexpected side effect of the RFC process is that time has become an 
important factor.  An RFC author can press ahead with a vote very shortly after 
introducing a topic, and an imposed 'cool down' period can prevent relevant 
discussion.

Agreed we can defer that discussion to a later time.

Zeev

Re: [PHP-DEV] Specific incident in relationship to the proposed Code of Conduct

[Derick Rethans]

On Sat, 23 Jan 2016, Stanislav Malyshev wrote:

> > I think we should have used temporary bans a bit more to cool down 
> > things. Including to myself along other.
> 
> Ban is a very dangerous thing, since it excludes people from discussion
> thus preventing it from reaching a conclusion, achieving consensus and
> closure, and it also hurts people and labels them ("ah, this guy who was
> already banned stirs up things again? let's just ignore him, he's
> obviously a troll").

But on the flip side, most of us are pretty good sporting trolling 
anyway, and I certainly have ignored threads where some people 
partipated because I didn't think it would contribute anything to the 
discussion. And that means you miss out on reasonable comments and 
opinions too.

> Stopping discussion by ban breeds resentment on the banned side and 
> taints whatever the other side achieved with "if I only were not 
> banned, I would prove you are wrong". Of course, there might be cases 
> where behavior turns destructive to the point consensus just can not 
> be reached, but if the person is still committed to overall goals of 
> the project, neutral third-party moderation would usually help. Not 
> 100% of cases, but usually. At least that's my conviction. So I think 
> using bans more "to cool things down" would not be healthy. Using 
> neutral third party to advise people to cool down (and maybe take a 
> break) might be.

Tthe balance needs to be found as to what's more important: seeing all 
good discussions and comments and inconvieniencing a persistent troll, 
or drawing out reasonable comments manually because of an issue being 
inconvienienced by a troll. I don't know the answer. A balance is 
important, and *perhaps* an option is to do allow for short term (in the 
order of days) "timeout periods" — in case the "please cool down" 
message is repeatly ignored.

However, in the first phase we ought to be discussing the goals, values 
and contributing guidelines. CoC, Mediation and (possible) enforcing is 
for later.

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

[PHP-DEV] Re: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no problem 5.5 or 5.3

[Lior Kaplan]

Please try the sources available from the website (e.g. 5.6.17), these are 
already have some files pre-generated.

Regradless, which versions of re2c/bison do you have on that system?

Kaplan


From: Ross, Christine 
Sent: Saturday, January 23, 2016 11:29 PM
To: internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: [PHP-DEV] compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Hello.

It was suggested I email this to this address.  I hope someone can help. I had 
no problems compiling php 5.3.# and 5.5.# on Sparc solaris 10 with Sun CC 12.3, 
but 5.6.# fails with the error below. GCC works but my whole application and 
environment is built with Sun CC. This is where it fails. I even tried adding 
/usr/sfw to the paths but no change.  I have received responses from others 
with the same issue.
Any help would be appreciated.



Lots of white space character errors before it fails on line 70. I saw 
something about flex and re2c so I installed re2c, and it didn't help. I tried 
without opcache, no help.

"Zend/zend_language_scanner.l", line 66: warning: invalid white space character 
in directive
"Zend/zend_language_scanner.l", line 67: warning: invalid white space character 
in directive
"Zend/zend_language_scanner.l", line 68: warning: invalid white space character 
in directive
"Zend/zend_language_scanner.l", line 69: warning: invalid white space character 
in directive
"Zend/zend_language_scanner.l", line 70: warning: function prototype parameters 
must have types
"Zend/zend_language_scanner.l", line 70: warning: old-style declaration or 
incorrect type for: SCNG
"Zend/zend_language_scanner.l", line 70: cannot initialize function: SCNG
"Zend/zend_language_scanner.l", line 70: undefined symbol: x

#!/bin/sh
#
# Configure PHP
#
PATH=/usr/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/sbin:/usr/dt/bin;
 export PATH
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/ssl/lib; export 
LD_LIBRARY_PATH
LD_RUN_PATH=/usr/local/ssl/lib:/usr/local/lib; export LD_RUN_PATH
#
env CC=cc CXX=CC \
../configure \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql=mysqlnd \
--with-pear \
--with-libxml-dir=/usr \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--enable-mbstring \
--with-curl \
--with-gd \
--with-jpeg-dir=/usr/lib \
--enable-soap \
--with-openssl=/usr/local/ssl \
--enable-zip \
--with-iconv=/opt/local \
--enable-opcache

#!/end
#

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

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

[Pavel Kouřil]

On Mon, Jan 25, 2016 at 9:21 AM, Stanislav Malyshev  wrote:
> Hi!
>
>> I already submitted it here once, so I'm skipping it - but I do
>> personally like how it says the project is about code.
>
> But it's not. Not only. Code is the result, sure, at least one of, but
> there's a lot of things involved that aren't code.
>

Well, kinda. If people just focused more on writing code and less on
discussing unrelated "clutter" (like someone's beliefs/gender/whatever
or even CoCs in general), then the need for some CoC fades away.

>> Actually, IMHO it is totally enough. The best CoC would be just a CoC
>> with one point:
>> 1. Be polite and behave like an adult.
>
> This is not a code in any meaningful sense except trivial - just as
> "main() {}" is a program in C, but not a useful one except for doing
> nothing. People's notions of "being an adult" differ. Now, it can be
> argued - and was argued - that we don't actually need a code, but then
> discussing details of the code is useless, of course.
>

Yes, I know - and I would like for people to take a step back and
think again whether or not they really need a CoC, and to think about
the reason why they need it - but not just "vague" what-ifs, but
reasons with some real backing, not just empty "buzzwords".

Also, either the CoC is gonna be vague in penalties (vague punishments
and stuff is slippery slope and bad) or will be long and try to define
bad behavior and penalties for them, only making the "trolls" use
loopholes to piss people off and be protected at the same time by CoC.
It's a lose-lose situation, IMHO.

>
>> If somebody harrases you or something, you can always sue him - and
>
> I think we should not disseminate legal advice here :) But without being
> a lawyer I can assure you suing somebody on the internet for trolling is
> not a winning proposition.

Well, I never said trolling, I said harassment - you know, stuff like
cyberstalking, death threats, etc. - the stuff that's really really
harmful and abusive and shouldn't be done. I would guess you can
definitely sue and win for that (or report it to police), depends
probably on the country you live in.

"Trolling" is a vague word with no clear-cut definition. Just kinda
another "buzzword".

Regards
Pavel Kouril

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

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

[Lester Caine]

On 25/01/16 05:23, Stanislav Malyshev wrote:
> For me, if people would use CoC to count how many times they sent a
> message on the list and then start arguing about *that* instead of the
> actual matter, then we made things worse, not better. The thought that
> somebody can be banned from discussion solely because they sent extra
> email per hour, or repeated an argument, makes me cringe. We certainly
> do not need anything like that here.

As someone who acknowledges that they perhaps send duplicate messages
when something irritates them, I think I can associate with that
statement. Slightly in defence, I would say that this is where the
debate between 'forum' and 'mail list' probably comes into play as to be
honest, I forget sometimes what has been said and am often replying to
the current quotes rather than reviewing the whole thread. Having the
whole thread on a forum would do nothing to solve that problem as with a
long debate you still only see a few messages but at least on my local
email archive I can scan back and now am to see just what I did say
before. That people fail to follow the etiquette set down to help make
the list more readable is probably a good example of why rules will get
broken anyway? I am now monitoring just what *I* have posted to a
thread, something which can't be done so easily on-line?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

[PHP-DEV] alternative valgrind-like support for run-tests along other nice additions

[Pierre Joye]

hi,

It has been a long due request to have something similar to valgrind
on Windows. I use a tool since quite some time for C projects and it
becomes so handy that it is now a good choice for testing PHP as well,
DrMemory (http://drmemory.org/)

It works on many other platforms as well and provide some other tools
and options that could be very handy for php as well. It uses their
toolset called DynamoRIO (http://www.dynamorio.org/) which is
amazingly powerful, brings strace for windows as well as many other
niches tools.

I made a quick port for run-tests.php -m using drmemory:

https://gist.github.com/pierrejoye/e53deffb7e069a67fc3f

(master). Draft stage, need cleanup of the log directory. Also willing
to provide a PR to their repo to support --logfile valgrind options
(will hopefully be discussed here
https://github.com/DynamoRIO/drmemory/issues/1853).

Be sure to have drmemory (1.9.x) in your path.

This is only for Windows but I think it could make sense to provide it
for other platforms as well, optionally. It can then allow us to
support other features more easily. I am particularly interested to
see if we can make some use of the fuzzy testing or use it to test our
internals APIs (what we cruelly miss now). I did not test the
performance but they claim to be faster than valgrind.

If there is any interest I can continue the port and make it available
on any supported platforms and create a RFC for it.

If not, I will simply apply the windows port so windows devs
(extension or core) can finally have something like valgrind.

Thoughts, ideas and comments welcome.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] Re: Reusing main VM stack for generators

[Dmitry Stogov]

On 01/25/2016 11:36 AM, Bob Weinand wrote:

Am 25.01.2016 um 09:13 schrieb Dmitry Stogov :

We basically need a way to properly first fetch the args (beware: func_arg 
fetches...) before instantiating the call frame, an issue which for example 
could be solved if we applied my vm_stack_restructuring patch (because it only 
installs call frames after all args were fetched).

I thought about that approach, but the amount of changes doesn't worth the 
result. Doing this only for generators doesn't make a lot of sense.

After all, we still have that 2% performance improvement. And the main VM stack 
reusage for Generators.

And I believe the proposed layout is also much more close to the C calling 
convention and thus more compatible if we ever go the route down to compiling 
to assembly.
Ultimately it gives us more flexibility as we also could put point the return 
temporary/cv of some opcodes to the right place, ready to call.
We aren't that far yet with the Optimizer, but I think I see it coming, where 
we'll benefit more from fixed places. It might be just a few moves less, but 
function arg passing is very common in PHP, so the benefit will be more 
significant the more optimizations we apply.

Remember that small thing removing ZEND_SEND_VAL_SPEC_TMP_TMP_HANDLERs where 
unnecessary? When we'll be able to know which variables may hold references or 
which not, we'll suddenly be able to directly write to the function parameter 
slot in much more cases.

I still stand by the point that doing it now (which small, but non-negligible 
improvement), will bring us a bigger improvement later. Many small improvements 
built around this patch will give us a big one in the end.


I put a note about "postponed" idea at https://wiki.php.net/php-7.1-ideas.
May be we will return to this later.

Thanks. Dmitry.

Thanks. Dmitry.



Thanks,
Bob



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

Re: [PHP-DEV] Re: Reusing main VM stack for generators

[Bob Weinand]

> Am 25.01.2016 um 09:13 schrieb Dmitry Stogov :
>> We basically need a way to properly first fetch the args (beware: func_arg 
>> fetches...) before instantiating the call frame, an issue which for example 
>> could be solved if we applied my vm_stack_restructuring patch (because it 
>> only installs call frames after all args were fetched).
> 
> I thought about that approach, but the amount of changes doesn't worth the 
> result. Doing this only for generators doesn't make a lot of sense.

After all, we still have that 2% performance improvement. And the main VM stack 
reusage for Generators.

And I believe the proposed layout is also much more close to the C calling 
convention and thus more compatible if we ever go the route down to compiling 
to assembly.
Ultimately it gives us more flexibility as we also could put point the return 
temporary/cv of some opcodes to the right place, ready to call.
We aren't that far yet with the Optimizer, but I think I see it coming, where 
we'll benefit more from fixed places. It might be just a few moves less, but 
function arg passing is very common in PHP, so the benefit will be more 
significant the more optimizations we apply.

Remember that small thing removing ZEND_SEND_VAL_SPEC_TMP_TMP_HANDLERs where 
unnecessary? When we'll be able to know which variables may hold references or 
which not, we'll suddenly be able to directly write to the function parameter 
slot in much more cases.

I still stand by the point that doing it now (which small, but non-negligible 
improvement), will bring us a bigger improvement later. Many small improvements 
built around this patch will give us a big one in the end.

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

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

[Stanislav Malyshev]

Hi!

> I already submitted it here once, so I'm skipping it - but I do
> personally like how it says the project is about code.

But it's not. Not only. Code is the result, sure, at least one of, but
there's a lot of things involved that aren't code.

> Actually, IMHO it is totally enough. The best CoC would be just a CoC
> with one point:
> 1. Be polite and behave like an adult.

This is not a code in any meaningful sense except trivial - just as
"main() {}" is a program in C, but not a useful one except for doing
nothing. People's notions of "being an adult" differ. Now, it can be
argued - and was argued - that we don't actually need a code, but then
discussing details of the code is useless, of course.

> rules doesn't make something it unsafe place. Basically, I don't think
> projects should act like a support group, but it seems it is the
> direction the CoCs try to push them.

I've never been in support group, so I'm not sure what is meant by "act
like a support group", but I guess where CoC pushes us depends on CoC?
That's why we spend time on figuring it out.

> If somebody harrases you or something, you can always sue him - and

I think we should not disseminate legal advice here :) But without being
a lawyer I can assure you suing somebody on the internet for trolling is
not a winning proposition.
-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: Reusing main VM stack for generators

[Dmitry Stogov]

On 01/22/2016 10:29 PM, Bob Weinand wrote:
Am 22.01.2016 um 15:43 schrieb Dmitry Stogov >:



Hi,

Could you please, take a look into the PoC.
It's incomplete, but may be you get ideas how to fix this.

https://gist.github.com/dstogov/285024375d15cacf2a9b

Few tests are failed, because YIELD may be used as expression in 
nested calls (between INIT_FCALL/DO_FCALL), and the caller function 
restores EG(vm_stack_top), loosing and overwriting that active frame.


valid(); $gen->send(0)) {
var_dump($gen->current());
}
?>

Thanks. Dmitry.


Hey, that's pretty similar to what I did 
https://github.com/php/php-src/commit/0f0471a9893230918084798d4e35db37d7b4519d 
 in 
that old patch, which you rejected because we hadn't found any 
solution for that issue with yield inside calls.


yes, this is similar.



We basically need a way to properly first fetch the args (beware: 
func_arg fetches...) before instantiating the call frame, an issue 
which for example could be solved if we applied my 
vm_stack_restructuring patch (because it only installs call frames 
after all args were fetched).


I thought about that approach, but the amount of changes doesn't worth 
the result. Doing this only for generators doesn't make a lot of sense.




I believe this patch won't work without significant refactoring (like 
vm_stack_refactoring branch) … so, either we bite the bullet and look 
at that patch again, or we can forget this idea too.


most probably, you are right.

Thanks. Dmitry.



Thanks,
Bob