Re: [PHP-DEV] Intention to move mcrypt to PECL

2016-10-05 Thread Pierre Joye 
On Thu, Oct 6, 2016 at 10:22 AM, Davey Shafik  wrote:
> On Wed, Oct 5, 2016 at 8:11 PM, Pierre Joye  wrote:
>>
>> hi Leigh,
>>
>> On Tue, Oct 4, 2016 at 11:58 PM, Leigh  wrote:
>> > Hello list,
>> >
>> > It is my intention to create a new PECL package for ext/mcrypt, so
>> > that it can be removed from master as per the RFC
>> > (https://wiki.php.net/rfc/mcrypt-viking-funeral)
>> >
>> > I do not expect there to be any updates to the extension after it has
>> > been migrated, however we voted to move it there.
>> >
>> > Any objections/comments? If not I'll apply for my PECL account in the
>> > next few days.
>>
>> I am not sure to follow.
>>
>> We rejected to move it out of the core for 7.0. This RFC is about
>> deprecation for 7.1.
>>
>> As much as I want to kill this beast as soon as possible, I do not
>> think we can kill it in 7.x but 8.x. It is also why I was pushing so
>> hard to kill it in 7.0, knowing that this will be tried again and
>> sadly for 7.x.
>
>
> From the RFC:
>
>> In PHP 7.1+1 (be it 7.2 or 8.0), the crypt extension will be moved out of
>> core and into PECL
>
> and
>
>> Vote “Yes” to raise an E_DEPRECATED notice in PHP 7.1 when any crypt
>> function is used and to remove the extension from core in 7.1+1.
>
> So, per the RFC, moving to PECL in 7.2 is correct.

"In PHP 7.1+1 (be it 7.2 or 8.0),"

I took it as 8, for the reason explained earlier.


-- 
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] Intention to move mcrypt to PECL

2016-10-05 Thread Davey Shafik 
On Wed, Oct 5, 2016 at 8:11 PM, Pierre Joye  wrote:

> hi Leigh,
>
> On Tue, Oct 4, 2016 at 11:58 PM, Leigh  wrote:
> > Hello list,
> >
> > It is my intention to create a new PECL package for ext/mcrypt, so
> > that it can be removed from master as per the RFC
> > (https://wiki.php.net/rfc/mcrypt-viking-funeral)
> >
> > I do not expect there to be any updates to the extension after it has
> > been migrated, however we voted to move it there.
> >
> > Any objections/comments? If not I'll apply for my PECL account in the
> > next few days.
>
> I am not sure to follow.
>
> We rejected to move it out of the core for 7.0. This RFC is about
> deprecation for 7.1.
>
> As much as I want to kill this beast as soon as possible, I do not
> think we can kill it in 7.x but 8.x. It is also why I was pushing so
> hard to kill it in 7.0, knowing that this will be tried again and
> sadly for 7.x.


>From the RFC:

> In PHP 7.1+1 (be it 7.2 or 8.0), the crypt extension will be moved out of
core and into PECL

and

> Vote “Yes” to raise an E_DEPRECATED notice in PHP 7.1 when any crypt
function is used and to remove the extension from core in 7.1+1.

So, per the RFC, moving to PECL in 7.2 is correct.

- Davey

Re: [PHP-DEV] Intention to move mcrypt to PECL

2016-10-05 Thread Pierre Joye 
hi Leigh,

On Tue, Oct 4, 2016 at 11:58 PM, Leigh  wrote:
> Hello list,
>
> It is my intention to create a new PECL package for ext/mcrypt, so
> that it can be removed from master as per the RFC
> (https://wiki.php.net/rfc/mcrypt-viking-funeral)
>
> I do not expect there to be any updates to the extension after it has
> been migrated, however we voted to move it there.
>
> Any objections/comments? If not I'll apply for my PECL account in the
> next few days.

I am not sure to follow.

We rejected to move it out of the core for 7.0. This RFC is about
deprecation for 7.1.

As much as I want to kill this beast as soon as possible, I do not
think we can kill it in 7.x but 8.x. It is also why I was pushing so
hard to kill it in 7.0, knowing that this will be tried again and
sadly for 7.x.

Cheers,
Pierre

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

[PHP-DEV] Re: [PECL-DEV] Intention to move mcrypt to PECL

2016-10-05 Thread Derick Rethans 
On Tue, 4 Oct 2016, Leigh wrote:

> Hello list,
> 
> It is my intention to create a new PECL package for ext/mcrypt, so
> that it can be removed from master as per the RFC
> (https://wiki.php.net/rfc/mcrypt-viking-funeral)
> 
> I do not expect there to be any updates to the extension after it has
> been migrated, however we voted to move it there.
> 
> Any objections/comments? If not I'll apply for my PECL account in the
> next few days.

It should be migrated properly, and also to GIT. I prefer that it is 
released with my username as "lead", as I wrote a big deal of it.

cheers,
Derick

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

Re: [PHP-DEV] Add support for HTTP/1.1

2016-10-05 Thread Kalle Sommer Nielsen 
Hi Rowan

On Oct 5, 2016 20:21, "Rowan Collins"  wrote:
>
> Hi all,
>
> It sounds like the feeling so far is quite positive. I'll have another
look for a dupe, then file a bug for the missing 100-continue support, and
try to work on a patch. Once that's in place, and unless anyone comes up
with other major features we need to support, we can discuss whether we
should make it the default, or at least easier to opt into.
>
>
>
> On 03/10/2016 09:43, Niklas Keller wrote ...:
>>
>> I think we already send it starting with 7.0, maybe just for 1.0,
because there are some servers that respond correctly with an HTTP/1.1
response to an HTTP/1.0 request, but fail to close the connection and imply
"Connection: close" for those requests.
>
>
> ... and on 05/10/2016 17:14, Andrea Faulds wrote:
>>
>> In order to connect to many modern websites, you need a Host: header,
and in order to use a Host: header, you need to use HTTP/1.1 (if you don't,
servers will sometimes send you back a 1.1 response anyway!).
>
>
> Indeed, checking 7.0 suggests that we are unconditionally sending both a
Host: header and Connection: Close with every request, while still claiming
"HTTP/1.0". I believe both headers are technically backwards compatible
with servers (i.e. ignored by) that genuinely speak HTTP/1.0, so this is
not technically "wrong". However, the fact that it's necessary does
strengthen the case for implementing HTTP/1.1 in full, rather than
backporting features bit by bit.
>
>
>
>
> On 04/10/2016 09:55, Björn Larsson wrote:
>>
>> Would fixing
>> this behaviour also be applicable for HTTPS?
>
>
> Yes, I'd be very surprised if this code wasn't shared between the two
contexts. (It's a little more complicated than just piping an "http"
connection through a "tls" one, because of things like SNI, but there'd be
no reason to have the actual header processing code twice.)

Afair then the code is separate in ext/standard/fopen_http_wrapper.c

>
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

RE: [PHP-DEV] ext/fileinfo/libmagic/apprentice.c", line 2195: error: syntax error

2016-10-05 Thread Anatol Belski 


> -Original Message-
> From: Dennis Clarke [mailto:dcla...@blastwave.org]
> Sent: Wednesday, October 5, 2016 5:00 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] ext/fileinfo/libmagic/apprentice.c", line 2195: error: 
> syntax
> error
> 
> 
> I tried the php-install mail list but saw no reply thus I will try here.
> 
> 
> While attempting a build of 7.0.11 I was presented with :
> 
> "/usr/local/build/php-
> 7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c",
> 
> line 2195: error: syntax error before or at: struct "/usr/local/build/php-
> 7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c",
> 
> line 2209: error: syntax error before or at: struct
> cc: acomp failed for
> /usr/local/build/php-
> 7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c
> gmake: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1
> 
> 
> The problem appears to be in a strange placement of the keyword "struct" :
> 
What is strange with the struct? Looks more like there is some missing some 
datatype or macro.

> 2189  private int
> 2190  parse_apple(struct magic_set *ms, struct magic_entry *me, const char
> *line)
> 2191  {
> 2192  struct magic *m = >mp[0];
> 2193
> 2194  return parse_extra(ms, me, line,
> 2195  CAST(off_t, offsetof(struct magic, apple)),
> 2196  sizeof(m->apple), "APPLE", "!+-./", 0);
> 2197  }
> 2198
> 
> also
> 
> 2203  private int
> 2204  parse_mime(struct magic_set *ms, struct magic_entry *me, const char
> *line)
> 2205  {
> 2206  struct magic *m = >mp[0];
> 2207
> 2208  return parse_extra(ms, me, line,
> 2209  CAST(zend_off_t, offsetof(struct magic, mimetype)),
> 2210  sizeof(m->mimetype), "MIME", "+-/.", 1);
> 2211  }
> 2212
> 
> 
> Not sure where the definition of "offsetof()" is located but something seems
> clearly not C compliant here.
> 
Just to be sure. If you include stddef.h directly, does it fix it? Normally 
stddef.h were included from php.h already, 

It could make sense otherwise to generate the preprocessed source and check the 
exact code produced. If you see something strange, it might be helpful to ifdef 
out some piece of code to check it were the cause. Otherwise, quite hard to 
guess what's happening, but likely some missing macro or datatype.

Regards

Anatol


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

Re: [PHP-DEV] Add support for HTTP/1.1

2016-10-05 Thread Rowan Collins 

Hi all,

It sounds like the feeling so far is quite positive. I'll have another 
look for a dupe, then file a bug for the missing 100-continue support, 
and try to work on a patch. Once that's in place, and unless anyone 
comes up with other major features we need to support, we can discuss 
whether we should make it the default, or at least easier to opt into.



On 03/10/2016 09:43, Niklas Keller wrote ...:
I think we already send it starting with 7.0, maybe just for 1.0, 
because there are some servers that respond correctly with an HTTP/1.1 
response to an HTTP/1.0 request, but fail to close the connection and 
imply "Connection: close" for those requests.


... and on 05/10/2016 17:14, Andrea Faulds wrote:
In order to connect to many modern websites, you need a Host: header, 
and in order to use a Host: header, you need to use HTTP/1.1 (if you 
don't, servers will sometimes send you back a 1.1 response anyway!).


Indeed, checking 7.0 suggests that we are unconditionally sending both a 
Host: header and Connection: Close with every request, while still 
claiming "HTTP/1.0". I believe both headers are technically backwards 
compatible with servers (i.e. ignored by) that genuinely speak HTTP/1.0, 
so this is not technically "wrong". However, the fact that it's 
necessary does strengthen the case for implementing HTTP/1.1 in full, 
rather than backporting features bit by bit.




On 04/10/2016 09:55, Björn Larsson wrote:

Would fixing
this behaviour also be applicable for HTTPS? 


Yes, I'd be very surprised if this code wasn't shared between the two 
contexts. (It's a little more complicated than just piping an "http" 
connection through a "tls" one, because of things like SNI, but there'd 
be no reason to have the actual header processing code twice.)


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Re: ext/fileinfo/libmagic/apprentice.c", line 2195: error: syntax error

2016-10-05 Thread Dennis Clarke 



Not sure where the definition of "offsetof()" is located but something
seems clearly not C compliant here.

So this is using the Oracle Studio 12.5 compiler tools on a big old
SPARC box running Solaris 10. Any input would be appreciated. The cflags
were permissive and allowed for transition type elements as I note that
C99 with strict compliance will fail horribly. The configure stage was
reasonably clean also.

In any case .. any input would be greatly appreciated.


offsetof() is supposed to be declared in [1].  Perhaps it
would need a typedef for your system?


hrmmm ... I don't think that is the issue here. Definately have that 
header and this is a POSIX compliant system for sure. In fact, from my

$HOME/.profile :


#
# ident "@(#)local.profile  1.10Dec 11 20:25:36 GMT 2014 ccode"
stty istrip
MAIL=/usr/mail/${LOGNAME:?}

# Standards, Environments, and Macros fully supported within UNIX
# ---
#This system supports IEEE Std 1003.1 and IEEE Std 1003.2,
#commonly  known  as  POSIX.1  and POSIX.2, respectively.
#Solaris 10 also  supports  the  X/Open  Common  Applications
#Environment (CAE) Portability Guide Issue 3 (XPG3) and Issue
#4 (XPG4); Single UNIX  Specification  (SUS,  also  known  as
#XPG4v2);  Single  UNIX Specification, Version 2 (SUSv2); and
#Single UNIX Specification, Version 3 (SUSv3). Both XPG4  and
#SUS  include  Networking  Services  Issue  4  (XNS4).  SUSv2
#includes Networking Services Issue 5 (XNS5).
#
#This is a fully LP64 (64-bit) environment and is fully
#compliant with The Open Group's UNIX 03 Product Standard.
#An application that wants to use standard-conforming  utili-
#tues  must  set  the PATH (sh(1) or ksh(1)) or path (csh(1))
#environment variable to specify the directories listed below
#in the order specified to get the appropriate utilities:
#
#POSIX.1-2001, SUSv3
#
#1.   /usr/xpg6/bin
#
#2.   /usr/xpg4/bin
#
#3.   /usr/ccs/bin
#
#4.   /usr/bin
#
#5.   directory containing binaries for your compiler
#
#6.   other directories containing binaries needed by
# the application
#
#When an application uses execlp() or execvp() (see  exec(2))
#to  execute a shell file, or uses system(3C), the shell used
#to interpret the shell file depends on the standard to which
#the caller conforms.
#
#See full details in standards(5) and at The OPEN Group(tm) or
#Oracle web sites.
#
# ---
PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/usr/jdk/latest/bin:/usr/local/ssl/bin:/usr/bin:/opt/developerstudio12.5/bin:/sbin:/bin:/usr/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/X11/bin:/opt/schily/bin:/usr/local/texlive/2012/bin/sparc-solaris
export PATH

pretty sure I can carve that back to just items 1 to 6 above and use C99 
compiler /opt/developerstudio12.5/bin/c99 and cflags options -Xc to be 
really really strict.


I think the error message is about the use of the "struct" keyword there.


[1] 


yep .. know it well.

I may just have to change the sources a wee bit and see what happens 
here. Maybe this is a GCC GNUism that snuck in.


dc


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

Re: [PHP-DEV] Re: ext/fileinfo/libmagic/apprentice.c", line 2195: error: syntax error

2016-10-05 Thread Bishop Bettini 
On Wed, Oct 5, 2016 at 12:51 PM, Dennis Clarke 
wrote:

>
> Not sure where the definition of "offsetof()" is located but something
>>> seems clearly not C compliant here.
>>>
>>> So this is using the Oracle Studio 12.5 compiler tools on a big old
>>> SPARC box running Solaris 10. Any input would be appreciated. The cflags
>>> were permissive and allowed for transition type elements as I note that
>>> C99 with strict compliance will fail horribly. The configure stage was
>>> reasonably clean also.
>>>
>>> In any case .. any input would be greatly appreciated.
>>>
>>
>> offsetof() is supposed to be declared in [1].  Perhaps it
>> would need a typedef for your system?
>>
>
> hrmmm ... I don't think that is the issue here. Definately have that
> header and this is a POSIX compliant system for sure. In fact, from my
> $HOME/.profile :
>
> pretty sure I can carve that back to just items 1 to 6 above and use C99
> compiler /opt/developerstudio12.5/bin/c99 and cflags options -Xc to be
> really really strict.
>
> I think the error message is about the use of the "struct" keyword there.
>
> [1] > stddef.h.html>
>>
>
> yep .. know it well.
>
> I may just have to change the sources a wee bit and see what happens here.
> Maybe this is a GCC GNUism that snuck in.


Commit 2181ed2

introduced the change, and I note that  is config guarded by
ifdef HAVE_STDDEF_H. So, perhaps check your configured values to see if
that header is detected properly.

[PHP-DEV] Re: ext/fileinfo/libmagic/apprentice.c", line 2195: error: syntax error

2016-10-05 Thread Christoph M. Becker 
On 05.10.2016 at 16:59, Dennis Clarke wrote:

> I tried the php-install mail list but saw no reply thus I will try here.
> 
> 
> While attempting a build of 7.0.11 I was presented with :
> 
> "/usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c",
> 
> line 2195: error: syntax error before or at: struct
> "/usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c",
> 
> line 2209: error: syntax error before or at: struct
> cc: acomp failed for
> /usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c
> 
> gmake: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1
> 
> 
> The problem appears to be in a strange placement of the keyword "struct" :
> 
>2189  private int
>2190  parse_apple(struct magic_set *ms, struct magic_entry *me, const
> char *line)
>2191  {
>2192  struct magic *m = >mp[0];
>2193
>2194  return parse_extra(ms, me, line,
>2195  CAST(off_t, offsetof(struct magic, apple)),
>2196  sizeof(m->apple), "APPLE", "!+-./", 0);
>2197  }
>2198
> 
> also
> 
>2203  private int
>2204  parse_mime(struct magic_set *ms, struct magic_entry *me, const
> char *line)
>2205  {
>2206  struct magic *m = >mp[0];
>2207
>2208  return parse_extra(ms, me, line,
>2209  CAST(zend_off_t, offsetof(struct magic, mimetype)),
>2210  sizeof(m->mimetype), "MIME", "+-/.", 1);
>2211  }
>2212
> 
> 
> Not sure where the definition of "offsetof()" is located but something
> seems clearly not C compliant here.
> 
> So this is using the Oracle Studio 12.5 compiler tools on a big old
> SPARC box running Solaris 10. Any input would be appreciated. The cflags
> were permissive and allowed for transition type elements as I note that
> C99 with strict compliance will fail horribly. The configure stage was
> reasonably clean also.
> 
> In any case .. any input would be greatly appreciated.

offsetof() is supposed to be declared in [1].  Perhaps it
would need a typedef for your system?

[1] 

-- 
Christoph M. Becker


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

[PHP-DEV] Re: Add support for HTTP/1.1

2016-10-05 Thread Andrea Faulds 

Hi Rowan,

Rowan Collins wrote:

I think it would be good to get this support into a better state, make
it easier to switch on - e.g. with an INI setting, or some new stream
URL syntax - and possibly make HTTP/1.1 the default in PHP 8.0.


HTTP/1.1 ought to be the default now, I think. The lack of the Host: 
header in HTTP/1.0 is pretty serious given how much of the web runs on 
vhosts now.



As I understand it, supporting HTTP/1.1 as a client requires the
following mandatory features on top of HTTP/1.0:

a) Send a "Host" header with every request. (RFC 7230 Section 5.4)
b) Support persistent connections, or send "Connection: Close" with each
request. (RFC 7230 Section 6.1)
c) Ignore 1xx status lines (notably, "100 Continue") "even if the client
does not expect one" (RFC 7231 Section 6.2)
d) Support "chunked" transfer encoding (RFC 7230 Section 4.1)

Let me know if there are any I've missed.


I don't know about ones you've missed, but the Host header, persistent 
connections and chunked transfer were the main ones that caught me out 
when I wrote my own minimal HTTP client a while ago. In order to connect 
to many modern websites, you need a Host: header, and in order to use a 
Host: header, you need to use HTTP/1.1 (if you don't, servers will 
sometimes send you back a 1.1 response anyway!). In order to understand 
the output of those servers, you may need chunked transfer encoding, 
particularly if they're running dynamic code (say, PHP), and you need to 
specify the connection is non-persistent, lest you wait forever.



What do people think? Would this be a worthwhile effort?


I think it's the absolute minimum we need to do to have it work properly 
at all. Using HTTP/1.0 alone probably means PHP's HTTP stream wrapper 
support is effectively broken at present, if my experiences are anything 
to go by.


Thanks for bringing this up!

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

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

[PHP-DEV] ext/fileinfo/libmagic/apprentice.c", line 2195: error: syntax error

2016-10-05 Thread Dennis Clarke 


I tried the php-install mail list but saw no reply thus I will try here.


While attempting a build of 7.0.11 I was presented with :

"/usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c", 


line 2195: error: syntax error before or at: struct
"/usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c", 


line 2209: error: syntax error before or at: struct
cc: acomp failed for
/usr/local/build/php-7.0.11_SunOS5.10_sparcv9.001/ext/fileinfo/libmagic/apprentice.c
gmake: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1


The problem appears to be in a strange placement of the keyword "struct" :

   2189  private int
   2190  parse_apple(struct magic_set *ms, struct magic_entry *me, const
char *line)
   2191  {
   2192  struct magic *m = >mp[0];
   2193
   2194  return parse_extra(ms, me, line,
   2195  CAST(off_t, offsetof(struct magic, apple)),
   2196  sizeof(m->apple), "APPLE", "!+-./", 0);
   2197  }
   2198

also

   2203  private int
   2204  parse_mime(struct magic_set *ms, struct magic_entry *me, const
char *line)
   2205  {
   2206  struct magic *m = >mp[0];
   2207
   2208  return parse_extra(ms, me, line,
   2209  CAST(zend_off_t, offsetof(struct magic, mimetype)),
   2210  sizeof(m->mimetype), "MIME", "+-/.", 1);
   2211  }
   2212


Not sure where the definition of "offsetof()" is located but something
seems clearly not C compliant here.

So this is using the Oracle Studio 12.5 compiler tools on a big old 
SPARC box running Solaris 10. Any input would be appreciated. The cflags 
were permissive and allowed for transition type elements as I note that 
C99 with strict compliance will fail horribly. The configure stage was 
reasonably clean also.


In any case .. any input would be greatly appreciated.

Dennis

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

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-10-05

2016-10-05 Thread lp_benchmark_robot 
Results for project PHP master, build date 2016-10-05 06:25:12+03:00
commit: 3f04ee0
previous commit:82a8e57
revision date:  2016-10-03 18:39:20-07: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.15% -0.05%  0.36%  
  7.24%
:-|   Drupal 7.36 cgi -T1  0.14% -0.04% -1.16%  
  5.04%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.03%  0.64%  
  3.45%
:-|   bench.php cgi -T100  0.13% -0.08% 29.96%  
  2.83%
:-(  micro_bench.php cgi -T10  0.19% -1.73% 10.37%  
  7.30%
:-|  mandelbrot.php cgi -T100  0.03%  0.01% 31.28%  
 -8.74%
---

* Relative Standard Deviation (Standard Deviation/Average)

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

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

Re: [PHP-DEV] Request for approval

2016-10-05 Thread Kalle Sommer Nielsen 
Hi Andrei,

You do not need a wiki account to comment, it is done on the php-internals
ML. Voting is restricted to php.net contributors and selected community
project representives

On Oct 5, 2016 10:45, "Andrei Popescu"  wrote:
>
> Hello,
>
> I'm the user "viperdel" and I would like to get access to the php wiki to
> comment, vote, etc.
>
> For the moment i'm interested in this:
>
> https://wiki.php.net/rfc/friend-classes
>
> --
>
> Best regards,
>
> Andrei Popescu

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

2016-10-05 Thread Yasuo Ohgaki 
Hi Leigh,

On Wed, Oct 5, 2016 at 5:25 PM, Leigh  wrote:
> The list was missed off of Yasuo's replies to me, replying including the
> list

Me too :)

>
> On Wed, 5 Oct 2016 at 01:07 Yasuo Ohgaki  wrote:
>>
>> Hi Leigh,
>>
>> On Tue, Oct 4, 2016 at 7:06 PM, Leigh  wrote:
>> > Since we want to preserve BC
>> >
>> > entropy = random_int(0, );
>> > uniqid = strpprintf(0, "%s%08x%05x.%08d", prefix, sec, usec, entropy);
>>
>> Current entropy is _double_ from php_combined_lcg() and has 10 chars
>> length,
>> has [0-9].[0-9]{8} format.
>>
>> "F"->"d" does not work. It should be something like
>>
>> entropy = (double) random_int(0, 99);
>
>
> No it shouldn't. Don't do this. It is an unnecessary conversion. The fact
> the lcg returns a double is irrelevant. What is relevant is the 8 digits in
> order to maintain BC. The 8 digits you receive from random_int will still be
> higher quality than the 10 you get from the lcg rounded to 8 places.
>
>>
>> uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
>> entropy/1);


There is misunderstanding for the format.
The patch is made to be fully compatible with current output.

php_combined_lcg()  produces value between 1 and 0. It is multiplied
by 10, and 8 decimal numbers are used, so additional entropy is
something like

1.23456789 (10 chars)

[yohgaki@dev ~]$ php -v
PHP 5.6.26 (cli) (built: Sep 16 2016 04:36:41)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

[yohgaki@dev ~]$ php -r 'var_dump(uniqid(), uniqid("", true));'
string(13) "57f4ce3df2ea5"
string(23) "57f4ce3df2ea81.98781982"

Current uniqid('', true) adds 1 int char + '.' + 8 decimal char.
Tricky format string, but this is what it does.

If we would like to avoid int to double conversion, we may call
php_random_int() twice. Not sure if it's worth or not, though.

Regards,

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

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

[PHP-DEV] Request for approval

2016-10-05 Thread Andrei Popescu 
Hello,

I'm the user "viperdel" and I would like to get access to the php wiki to
comment, vote, etc.

For the moment i'm interested in this:

https://wiki.php.net/rfc/friend-classes

-- 

Best regards,

Andrei Popescu

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Improve uniqid() uniqueness

2016-10-05 Thread Leigh 
The list was missed off of Yasuo's replies to me, replying including the
list

On Wed, 5 Oct 2016 at 01:07 Yasuo Ohgaki  wrote:

> Hi Leigh,
>
> On Tue, Oct 4, 2016 at 7:06 PM, Leigh  wrote:
> > Since we want to preserve BC
> >
> > entropy = random_int(0, );
> > uniqid = strpprintf(0, "%s%08x%05x.%08d", prefix, sec, usec, entropy);
>
> Current entropy is _double_ from php_combined_lcg() and has 10 chars
> length,
> has [0-9].[0-9]{8} format.
>
> "F"->"d" does not work. It should be something like
>
> entropy = (double) random_int(0, 99);
>

No it shouldn't. Don't do this. It is an unnecessary conversion. The fact
the lcg returns a double is irrelevant. What is relevant is the 8 digits in
order to maintain BC. The 8 digits you receive from random_int will still
be higher quality than the 10 you get from the lcg rounded to 8 places.


> uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
> entropy/1);
>




On Wed, 5 Oct 2016 at 01:16 Yasuo Ohgaki  wrote:

> On Wed, Oct 5, 2016 at 9:06 AM, Yasuo Ohgaki  wrote:
> > Current entropy is _double_ from php_combined_lcg() and has 10 chars
> length,
> > has [0-9].[0-9]{8} format.
> >
> > "F"->"d" does not work. It should be something like
> >
> > entropy = (double) random_int(0, 99);
> > uniqid = strpprintf(0, "%s%08x%05x.%08F", prefix, sec, usec,
> entropy/1);
>
> Forgot to mention, this code leak more information about PRNG state
> than my patch because php_random_int() copies random binary data into
> long. It's still part of it and exposure of random data shouldn't
> matter, so this is minor issue.
>

I think there is a misunderstanding here. You're using the CSPRNG which is
designed such that the _entire_ output can be made public without you being
able to predict the next result. That is the definition of a CSPRNG. Also
remember this is "output" not "state".

While researching how to implement these CSPRNG functions, I spoke with
real security experts on the subject, they all said the same thing: Use the
system CSPRNG, and yes, it is fine to expose the output directly.

Also if you really are worried (which you shouldn't be), requesting 8
digits from random_int will effectively discard 5 or 37 bits of output
depending on whether you're on a 32 or 64 bit platform. You cannot know the
value of sequential outputs.


> I'll update gist.
> Any more comments?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

[PHP-DEV] Re: RFC: Strict comparisons

2016-10-05 Thread Vesa Kaihlavirta 
On Mon, 19 Sep 2016 at 16:04 Vesa Kaihlavirta  wrote:

> Hey all,
>
> I've been bouncing this idea of fixing all comparison operations in one
> fell swoop, although with an opt-in declare in the spirit of strict_types.
>
> So, I thought about this for a while, and decided against doing this RFC
myself. If anyone else wants to pick it up, go ahead.

Best of luck to you all!

--vk