Re: [PHP-DEV] [IDEA] allow extending enum

[Davey Shafik]

> On Mar 29, 2023, at 06:56, Rowan Tommins  wrote:
> 
> On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius  wrote:
> 
>> Ok so I am trying to find the argumentation here:
>>> This is by design.
>>> The point of enums is to be limiting.
>> This is clearly an assumption. That statement is not in the docs or
>> RFC, nor such an oversimplification makes logical sense to me, but
>> maybe you have a source to back it up..?
> 
> 
> From a theory point of view, *any* type definition is about limiting
> allowed values. The difference between "mixed" and "integer" is that
> "mixed" allows both 'Hello' and 42, but "integer" does not - it defines a
> tighter limit.
> 
> In the same way, saying "I accept an error code" means "I accept an error
> code *and nothing else*" - the definition of what is and what isn't an
> "error code" is deliberately a *limit* on the values that you accept.
> 
> 
> 
>>> Re: problem in the OP
>>> You are approaching the design of this in a fundamentally wrong way.
>> The described problem is dealing with error *codes* not *types*
> 
> 
> 
> An enum is a type, so that's why George was talking about types. He was
> making the same point, in different words, as I did: the relationship
> between types implied by the keyword "extends" is not the relationship you
> want in this case.
> 
> 
> 
>> The set in question is *finite*, as you say of course, but much larger
>> and different in principle than in the solution you are proposing.
>> Problem in OP is looking for a way for end users to keep adding new
>> domains to the error codes passed to the parent system to be handled.
> 
> 
> This is the key point - if you pass an error code that didn't previously
> exist, the existing system *won't* be able to handle it.
> 
> That's why enums are inherently restrictive: the system wants to be able to
> say "this is the list of error codes I understand, don't give me anything
> else".
> 
> If you have a system that accepts the new codes as well as the old ones,
> you can use a union type declaration as George says:
> 
> enum AdditionalErrorCode {
>   case Code_456;
> }
> 
> class ExtendedErrorHandler extends StandardErrorHandler {
>   public function handle(StandardErrorCode|AdditionalErrorCode $code) {
>switch ( $code ) {
>case AdditionalErrorCode::Code_456:
>   // handling for new code goes here
>break;
>default:
>// assert($code instanceof StandardErrorCode);
>parent::handle($code);
>break;
>   }
>   }
> }

The issue of contention here is that inheritance isn't the correct mechanism 
for reusing enum definitions to expand on them. What about allowing "use" 
syntax  like traits?

enum HttpErrors {
   case HTTP_STATUS_400;
   case HTTP_STATUS_401;
…
}

enum ApiErrors {
   use HttpErrors;

   case JsonParserError;
   case GraphQLParserError;
}

Now you have ApiErrors::HTTP_STATUS_400 etc without ApiErrors being is-a 
HttpErrors.

- Davey

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

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Davey Shafik]

On Tue, Jun 16, 2020 at 1:34 PM Nikita Popov  wrote:

> On Tue, Jun 16, 2020 at 10:28 PM Davey Shafik  wrote:
>
>>
>>
>> On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov 
>> wrote:
>>
>>> Hi internals,
>>>
>>> Inspired by the recent discussion on reserved keyword reservation, I'd
>>> like
>>> to propose the following RFC:
>>>
>>> https://wiki.php.net/rfc/namespaced_names_as_token
>>>
>>> This RFC makes two related changes: Treat namespaced names as a single
>>> token, which enables use of reserved keywords inside them. And remove
>>> reserved keyword restrictions from various declarations.
>>>
>>> The RFC comes with a small backwards compatibility break related to names
>>> that include whitespace, but will hopefully reduce the backwards
>>> compatibility impact of future reserved keyword additions.
>>>
>>> Regards,
>>> Nikita
>>>
>>
>> The only issue I have with this RFC is this:
>>
>> use Foo as KEYWORD;
>>
>> While this might be _technically_ correct, it is unusable. That is:
>>
>> use Foo as List;
>>
>> class Bar extends List { } // this will not work
>>
>
> That's correct. However, "class Bar extends List\FooBar" will work.
>

Hadn't considered this! Good point.


>
> I mainly allow this because "use Foo\Bar" is the same as "use Foo\Bar as
> Bar". If "use Foo\List" is allowed, it makes little sense to forbid the
> equivalent "use Foo\List as List".
>
> Given this, I think this specific syntax should be an error, unless I'm
>> missing something?
>>
>
Looks like I was, consider my concern assuaged :)


>
>> Also, does this mean we can alias to fully namespaced names now?
>>
>> use \My\Foo as \Bar\Foo;
>> class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
>> \Bar\Foo (no autoload would happen?)
>>
>
> No, this continues to be not allowed. "As" does not accept a namespaced
> name, it accepts a single identifier.
>

But now the namespace _is_ a single identifier. Or at least, it creates
some (minimal) confusion here IMO.

- Davey

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Davey Shafik]

On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov  wrote:

> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita
>

The only issue I have with this RFC is this:

use Foo as KEYWORD;

While this might be _technically_ correct, it is unusable. That is:

use Foo as List;

class Bar extends List { } // this will not work

Given this, I think this specific syntax should be an error, unless I'm
missing something?

Also, does this mean we can alias to fully namespaced names now?

use \My\Foo as \Bar\Foo;
class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
\Bar\Foo (no autoload would happen?)

- Davey

Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2

[Davey Shafik]

On Fri, May 22, 2020 at 4:09 AM Ilija Tovilo  wrote:

> Hi internals
>
> I'd like to announce the match expression v2 RFC:
> https://wiki.php.net/rfc/match_expression_v2
>
> The goal of the new draft is to be as simple and uncontroversial as
> possible. It differs from v1 in the following ways:
>
> * Blocks were removed
> * Secondary votes were removed
> * optional semicolon
> * omitting `(true)`
> * Unimportant details were removed (e.g. examples for future scope)
>
> You can look at the diff here:
> https://github.com/iluuu1994/match-expression-rfc/pull/8/files
>
> I will also leave the discussion period open for longer as that too
> was one of the primary criticisms.
>
> As mentioned by Kalle:
>
> > Resurrecting rejected RFCs have a "cooldown" of 6 months:
> > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
>
> That is, unless:
>
> > The author(s) make substantial changes to the proposal. While it's
> > impossible to put clear definitions on what constitutes 'substantial'
> > changes, they should be material enough so that they'll significantly
> > affect the outcome of another vote.
>
> Given that many people have said without blocks they'd vote yes I'd
> say this is the case here. Let me know if you don't agree.
>
> Ilija
>

With these simplifications, I'm not entirely sure there is enough value
here if the Conditional Return, Break, and Continue Statements RFC is
passed. This could be written with the slightly more ugly, but serviceable:

So this:
$statement = match ($this->lexer->lookahead['type']) {
Lexer::T_SELECT => $this->SelectStatement(),
Lexer::T_UPDATE => $this->UpdateStatement(),
Lexer::T_DELETE => $this->DeleteStatement(),
default => $this->syntaxError('SELECT, UPDATE or DELETE'),
};

could be expressed as:

echo (function($match) {
return $this->SelectStatement() if ($match === Lexer::T_SELECT);
return $this->UpdateStatement() if ($match === Lexer::T_UPDATE);
return $this->DeleteStatement() if ($match === Lexer::T_DELETE);
return $this->syntaxError('SELECT, UPDATE or DELETE');
})($this->lexer->lookahead['type']);

I mean, ultimately, it's equivalent to:

echo (function($match) {
if ($match === Lexer::T_SELECT) {
return $this->SelectStatement()
}
if ($match === Lexer::T_UPDATE) {
return $this->UpdateStatement()
}
if ($match === Lexer::T_DELETE) {
return $this->SelectStatement()
}
return $this->syntaxError('SELECT, UPDATE or DELETE');
})($this->lexer->lookahead['type']);

The main selling point for match is that it's more concise, I'm not
convinced that the return if variant is much less concise. If you want to
match more than one thing, use the OR (double pipe) operator in the if
condition.

Having said that… match is undeniably prettier. If we are doing this
however, I'd prefer to implement Go's switch block, named match because we
already have a switch. It's strict, but flexible.

- Davey

Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0

[Davey Shafik]

dopOn Fri, May 22, 2020 at 3:58 AM Nikita Popov 
wrote:

> On Thu, May 21, 2020 at 11:54 PM Rowan Tommins 
> wrote:
>
> > Hi all,
> >
> > A few years ago, I posted a message suggesting that PHP improve support
> > for HTTP/1.1 in its stream wrapper functions:
> > https://externals.io/message/96192
> >
> > A quick summary of the current situation:
> >
> > * HTTP/1.1 was officially standardised in January 1997, and most web
> > browsers had already implemented it by then
> > * PHP has a very simple HTTP client implementation, used by the "http:"
> > and "https:" stream wrappers, and also by extensions which make HTTP
> > requests, such as ext/soap
> > * The client implementation defaults to advertising HTTP/1.0 requests,
> > unless over-ridden by a stream context option
> > * Since a lot of servers only actually talk HTTP/1.1, the client mostly
> > acts as an HTTP/1.1 client even when advertising HTTP/1.0
> >
> >
> > In my previous message, I identified four requirements in HTTP/1.1 but
> > not HTTP/1.0 that are relevant to a client:
> >
> > 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)
> >
> >
> > The PHP client now supports all four regardless of protocol version
> > configured, i.e. it always sends "Host:" and "Connection: Close"
> > headers; and always handles "100 Continue" and "Transfer-Encoding:
> > Chunked" if returned by the server.
> >
> > I would like to propose that the client advertises HTTP/1.1 in its
> > requests by default in PHP 8.0.  Users can opt out of this behaviour in
> > a fully backwards- and forwards-compatible way if necessary using a
> > stream context option, e.g.:
> > https://gist.github.com/IMSoP/a685fed6589435530102d57138755511
> >
> >
> > What are people's opinions? Does this need an RFC, or should I just
> > submit a PR if nobody objects?
> >
>
> Sounds good to me. Assuming there are no objections, feel free to just send
> a PR.
>
> @Eliot: Unfortunately we don't implement HTTP 2 in the http:// stream
> wrapper, so HTTP 1.1 is the best we can do there right now. We only provide
> HTTP 2 support through the curl extension. Implementing HTTP 2 support
> would certainly be a possibility, but I don't think it's particularly easy
> to do so without pulling in a dependency like nghttp2.
>
> @Max: I'm only guessing here, because I'm not familiar with the historical
> context, but I imagine part of the motivation is to support HTTP requests
> in a minimal build of PHP, which does not have any dependencies (that we do
> not bundle ourselves).
>
> We did actually provide an implementation of the http:// stream wrapper
> via
> curl for a long time, but dropped it at some point, because there were many
> subtle behavior differences to our native implementation.
>
> Regards,
> Nikita
>

This is ridiculously timely as I've been spending my evening working on
HTTP/2 stuff in PHP.

This might be a good time to reopen discussion of adding support for HTTP/2
in PHP with the inclusion of libnghttp2. I posted a long time ago about
adding support for HTTP/2 to the CLI server and the http stream using
libnghttp2 [1].

I think PHP 8.0 would be a perfect opportunity to revisit this given that
HTTP/2 has now reached ~97% adoption[2] and HTTP/3 is on the horizon.

I believe that HTTP/2 has the potential to dramatically change how we serve
content on the web, and PHP should jump on the bandwagon.

- Davey

[1] https://externals.io/message/89932
[2] https://caniuse.com/#search=http%2F2

Re: [PHP-DEV] [RFC] <> Attribute

[Davey Shafik]

On Thu, May 7, 2020 at 01:18 Benjamin Eberlei  wrote:

>
>
> On Thu, May 7, 2020 at 10:10 AM Davey Shafik  wrote:
>
>>
>>
>> On Thu, May 7, 2020 at 00:22 Benjamin Eberlei 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> The attributes RFC specifically looked into the use of attributes at the
>>> engine/compiler level.
>>>
>>> To have a showcase of this with the 8.0 release I want to propose this
>>> RFC
>>> for a <> attribute:
>>>
>>> https://wiki.php.net/rfc/deprecated_attribute
>>>
>>> <> is the most obvious engine attribute to add at the
>>> beginning
>>> in my opinion, as
>>>
>>> - all other languages with Attributes/Annotations support have it as well
>>> - its effects are quite obvious to understand, as such offer a good
>>> example
>>> and intro to attributes
>>> - with potential property/class constant deprecation it adds something
>>> that
>>> was not possible in userland before.
>>>
>>> Let me know what you think!
>>>
>>> greetings
>>> Benjamin
>>
>>
>> Hi Benjamin,
>>
>> Two things:
>>
>> 1) as a matter of course, I prefer things that can be done in userland be
>> done in userland unless there is a clear performance or other win. This
>> doesn't qualify for me, except that it would be possible to use the same
>> mechanism in core, but that really only gives us the ability to reason
>> around depredations with reflection and I don't see much value in that. I'm
>> not entirely convinced that a PSR and a defecto implementation isn't a
>> better solution here. This isn't a show-stopper though.
>>
>
> Can you clarify a bit your argument "ability to reason around deprecations
> only with reflection"?
>
> At the moment we can only reason about deprecations by using both
> token_get_all and finding that a method calls trigger_error
> E_USER_DEPRECATED and by looking at the doc comments (via reflection) for
> "@deprecated". My argument for this attribute is that it leads to both a
> documentation based deprecation, and a runtime declaration at the same
> time. It is a better result than what we can do in userland in my opinion.
>

I don't see any valid reason to be checking for deprecations at runtime
with reflection. This attribute has more value when reading the code or
doing static analysis. Neither of which requires that it be implemented in
core. Plus, userland gives us the reflection ability *anyway*.


>
>
>>
>> 2) AFAICT you cannot add an attribute to a function argument, and the
>> only way I can see to resolve that is to add a "DeprecatedArgument"
>> attribute applied to the function that takes the name as the first arg (and
>> the message as the second). Now you're looking at:
>>
>> <>
>> <>
>> function bat($foo = null, $bar = null) { }
>>
>> It's not great IMO. Having said that, I don't think this bit is really
>> necessary — unlike the other suggested uses, an argument isn't an isolated
>> thing, so much as part of the function signature as a whole and removing
>> arguments is better done by deprecating the entire function and introducing
>> a new version with a different name. So maybe we just don't need this?
>>
>
> It is possible to add attributes to parameters. This was added as an
> improvement during the Attributes RFC (it was not possible in the first
> draft).
>

I went back and looked and still missed that, oops! I still stand by my
statement about it being bad practice ;)

- Davey

Re: [PHP-DEV] [RFC] <> Attribute

[Davey Shafik]

On Thu, May 7, 2020 at 00:22 Benjamin Eberlei  wrote:

> Hi everyone,
>
> The attributes RFC specifically looked into the use of attributes at the
> engine/compiler level.
>
> To have a showcase of this with the 8.0 release I want to propose this RFC
> for a <> attribute:
>
> https://wiki.php.net/rfc/deprecated_attribute
>
> <> is the most obvious engine attribute to add at the beginning
> in my opinion, as
>
> - all other languages with Attributes/Annotations support have it as well
> - its effects are quite obvious to understand, as such offer a good example
> and intro to attributes
> - with potential property/class constant deprecation it adds something that
> was not possible in userland before.
>
> Let me know what you think!
>
> greetings
> Benjamin


Hi Benjamin,

Two things:

1) as a matter of course, I prefer things that can be done in userland be
done in userland unless there is a clear performance or other win. This
doesn't qualify for me, except that it would be possible to use the same
mechanism in core, but that really only gives us the ability to reason
around depredations with reflection and I don't see much value in that. I'm
not entirely convinced that a PSR and a defecto implementation isn't a
better solution here. This isn't a show-stopper though.

2) AFAICT you cannot add an attribute to a function argument, and the only
way I can see to resolve that is to add a "DeprecatedArgument" attribute
applied to the function that takes the name as the first arg (and the
message as the second). Now you're looking at:

<>
<>
function bat($foo = null, $bar = null) { }

It's not great IMO. Having said that, I don't think this bit is really
necessary — unlike the other suggested uses, an argument isn't an isolated
thing, so much as part of the function signature as a whole and removing
arguments is better done by deprecating the entire function and introducing
a new version with a different name. So maybe we just don't need this?

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

[Davey Shafik]

On Wed, Apr 29, 2020 at 08:24 Benas IML  wrote:

> Hello,
>
> > Again, your assumption that just about everyone uses namespaced classes
> > doesn't take into account closed source projects. I don't care if it's a
> major
> > release or not - BC breaks should always be avoided without a major
> benefit
>
> With an introduction of any new language construct, function, class or
> constant, we don't know whether it affects closed source projects and we
> can't.
> So using your own logic, you can't assume that closed source projects use
> `Attribute` either.
>
> Another key term to take into consideration from my email is "in such cases
> isn't the first priority". That doesn't mean it doesn't matter, so please
> don't
> change my words as you please. Since PHP has global namespace reserved,
> things
> like implementation details matter much more **in such cases**.
>
> > str_contains adds functionality to PHP. We aren't debating whether to add
> > attribute functionality to PHP, but what to call it. As such, this
> argument is
> > an invalid comparison.
>
> What I meant by `str_contains()` was its name. There were multiple PHP
> projects
> that offered a global helper function called `str_contains()`. As such,
> introduction of this function was also a name clash for them.
>
> > As I said above, I'm ambivalent about this particular issue. However, I
> get
> > nervous when I start to see the "Who cares if it breaks stuff" or "Well,
> they
> > shouldn't be doing it that way, so screw them" arguments pop up. While
> the
> > chances of a BC break might be minimal using "Attribute" - I don't think
> that
> > PhpAttribute is an undue burden in an attempt to avoid such instances,
> nor is
> > it logically inconsistent with other Php* named classes.
>
> Well then you shouldn't take everything so "harshly" and as a debate. There
> are
> no "arguments" here, I am simply expressing my own opinion.
>
> As for naming inconsistencies, Rowan addressed that already.
>
> Best regards,
> Benas Seliuginas.


Hi all,

IMO, the onus of proof should be on those wishing to introduce a change
that has a potential conflict, not those trying to prevent one.

I believe that using the PHP namespace is the right way to go, and look
forward to seeing code like this in the future:

>
class Foo { }

- Davey

Re: [PHP-DEV] RFC proposal: Provide support for XSLT 3.0, XPath 3.1, and XQuery 3.1

[Davey Shafik]

On Tue, Oct 3, 2017 at 1:29 PM, Walter Parker  wrote:

> On Tue, Oct 3, 2017 at 7:51 AM, Dan Ackroyd 
> wrote:
>
> > Hi O'Neil,
> >
> > On 3 October 2017 at 10:04, O'Neil Delpratt  wrote:
> > > Hi,
> > >
> > > We are considering submitting an RFC along the following lines and
> > welcome your comments:
> > >
> > > Enhancing the existing XSLTProcessor is not an option: it has fallen
> too
> > far behind for this to be viable.
> >
> > That's probably true.
> >
> > > Excelsior have a licensing scheme enabling the compiler to be used by
> > open source
> > > projects (see: https://www.excelsiorjet.com/free <
> > https://www.excelsiorjet.com/free>).
> >
> > I don't have the multiple hours available now to fully read through
> > and comprehend all the license information, however there are some red
> > flags from my initial reading:
> >
> > > Instead, we now offer free personal licenses for that Edition to all
> > prospects
> > > who opt in when evaluating Excelsior JET.
> > > 
> > > Evaluate Excelsior JET and get a free Standard Edition license for your
> > personal use:
> > > ...
> > > If you do not wish to receive a free license, you may skip the
> > registration and
> > > download Excelsior JET Evaluation Packages anonymously.
> >
> > Having to register and opt in to obtain a license, seems like a problem.
> >
> > > Caveat #1: The Excelsior JET Runtime cannot be used in embedded systems
> > > due to a licensing restriction.
> >
> > That seems like a problem.
> >
> > > Caveat #2: The Standard Edition is essentially an entry‑level variant
> of
> > > the product, which means that: It is not available for OS X.
> >
> > That seems like a problem.
> >
> > With regards to the more technical aspects of the proposal.
> >
> > Can you say how much bigger including all of the relevant libraries
> > would make the PHP executable? Some people have already expressed
> > concern at how large the default PHP executable has become.
> >
> > What I would suggest is, if you think the license issues can be
> > resolved, to apply for a PECL account at http://pecl.php.net/ and
> > start having people to start using the extension through there.
> >
> > Having a quick look at the extension source code, I get the impression
> > that having more people use it could result in lots of small
> > refinements to the implementation that should be done before the
> > extension was ready to bring into PHP core.
> >
> > cheers
> > Dan
> > Ack
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> From the ExcelsiorJet FAQ Page:
> Is the Excelsior JET license GPL-compatible?
> 
>
> Unfortunately, no. Excelsior JET includes the Java SE API source code
> licensed from Oracle under OCSL Commercial Use license, which is not
> GPL-compatible. So even releasing our own code under the GPL won't help.
> LGPL is fine however.
>
> We suggest you to release the natively compiled binary under a different
> license, pointing out that the source code is available under the GPL. You
> would however need the consent of all contributors.
> Does new code to the core have to be GPL-compatible? Or has it changed to
> LGPL. This may be a showstopper.
>
> Also, the fact it only generates 32-bit code may also be a non starter, as
> lots of Linux & BSD systems are now running 64-bit as the default/common
> install.
>
>
> Walter
>

You seem to be mistaken in thinking the PHP project is GPL licensed. It is
in fact licensed under the PHP License[1], and AFAIK does not allow
GPL-licensed in core (LGPL is fine)…

[1] http://php.net/license/3_0.txt

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Davey Shafik]

I believe the correct solution to this is an OuterIterator — an
OuterIterator contains the logic to constrain the loop, for example, we
have the LimitIterator, FilterIterator, RegexIterator, etc.

See this example:
http://php.net/manual/en/class.limititerator.php#example-4473

You can build your own OuterIterators, which implements whatever logic your
Reader should have.

OuterIterators are also compose-able, you can stack them, though of course
there are performance considerations here.

I would say that any alternative to OuterIterator's should have a clear and
demonstrable benefit in both developer experience, and performance before
it should be considered.

- Davey

On Wed, Jul 5, 2017 at 3:51 AM, Rowan Collins 
wrote:

> On 3 July 2017 16:58:16 BST, Andreas Hennings  wrote:
> >My motivation was to be able to use iterators and readers
> >interchangeably.
> >Readers are easier to implement as classes.
> >Iterators have the benefit of the generator syntax.
> >The idea is to have a library where some stuff is implemented as
> >reader classes, and some other things are implemented as iterator
> >classes.
> >
> >Then for the actual operational code, I need to choose to use either
> >iterator syntax or reader syntax. So either I need adapters for all
> >iterators, or I need adapters for all readers.
>
> An alternative to adapters in this case might be a Trait that allows you
> to write the class as a Reader, but turn it into a fully-functioning
> Iterator with one line of code. If you always call your read method read()
> you only need a single adapter which calls that at the appropriate times
> and buffers the value to know if it's reached the end. That adapter could
> be "pasted" by a Trait into each class where read() is defined, and read()
> could even be private.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Davey Shafik]

It should be noted that Certificate Authorities (CAs) haven't been issuing
SHA-1 certs since December 31st 2015.

I think the best solution if possible, would be to treat MD5 and SHA-1
certs as invalid in _all_ supported versions of PHP and requiring that
the verify_peer
option be set to false to accept them.

For PHP 7.2 also add deprecation notices.

For PHP 7.3 and later, remove support completely.

On Mon, Jul 3, 2017 at 11:11 AM, Niklas Keller  wrote:

> 2017-07-03 19:24 GMT+02:00 Sara Golemon :
>
> > On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller  wrote:
> > > Additionally there will be two INI options
> > > which are only added to PHP 7.1 and 7.0 to allow people to immediately
> > > upgrade to secure defaults without any risk of breaking other apps.
> > >
> > I understand what you're going for there, but it's just a bit weird to
> > have that INI option exist for a weird pair of version ranges and not
> > forward.   I'd say keep the INI in 7.2 and (perhaps) mark them
> > deprecated.  There's no sense making that upgrade path unreasonably
> > difficult.
> >
>
> True, but I'd like it to be an INI option to strengthen the security, but
> not allow to weaken it. You really shouldn't use MD5 or SHA1 for TLS
> certificates 2018 (!). If you really need it there, you can still set a
> default stream context option, but we won't clutter the INI options of
> future versions.
>
> Regards, Niklas
>

Re: [PHP-DEV] PHP_OS_FAMILY and macOS

[Davey Shafik]

Given that iPad (and iPhone) both run iOS which is based on Darwin, and
Apple just relaxed the rules on running interpreted code, and we are
already seeing IDEs spring up for the device, we should use "Darwin",
rather than "Mac". This also encompasses other distros like PureDarwin.

- Davey



On Tue, Jun 13, 2017 at 6:47 AM, Sebastian Bergmann 
wrote:

> Am 13.06.2017 um 15:00 schrieb Zeev Suraski:
> > Yep, Mac sounds like a fairly future-proof choice, and is also
> consistent with the capitalization of other options.
>
> Implemented in
> http://git.php.net/?p=php-src.git;a=commitdiff;h=
> 362d2e42a02fe018a7d1261a53ff59b73fed91f6
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[Davey Shafik]

Pedro,

It would be best to just kill the vote and start over. The proposal should
be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should
be one vote, as doing both together should be the only option.

- Davey

On Sun, Jun 11, 2017 at 8:25 AM, Pedro Magalhães  wrote:

> On Thu, Jun 8, 2017 at 9:52 AM, François Laupretre 
> wrote:
> >
> > I am sorry you take it this way. Voting today on a feature for 8.0
> > wouldn't be ridiculous and it would make me change my vote, as most
> others.
> > Instead of nonsense, it would be a sign of maturity for the PHP project.
> It
> > would be great, IMO, to open a 'Approved for 8.0' section on the RFC page
> > now, and your RFC could proudly be the 1st one to enter it.
> >
>
> I agree with your suggestion and general sentiment so I propose to do the
> following:
>
>- The current voting widget refers to introducing the change on 7.2.
>(Will be mentioned on the RFC page)
>- Add a new voting widget for introducing the change on 8.0.
>- Extend the voting period for one more week than originally planned
>until 27/6/2017 18:00 UTC.
>
> Additionally, since some people also mentioned the difficulty in detecting
> this change, if the vote for 8.0 passes, I suggest to introduce a
> E_DEPRECATED notice where the implicit keys will change. You can see that
> implementation here:
> https://github.com/php/php-src/compare/master...pmmaga:
> negative-array-deprecated
> Would it make sense to include an extra voting widget for the introduction
> of the notice?
>
> Given that we are on the voting phase I would oppose changing anything by
> principle, but given that most of the discussion on the topic only started
> when the vote was started and what is dividing the vote is the timing, I
> think it makes sense to update the RFC in this case. Let me know what you
> think.
>
> Thanks,
> Pedro
>

Re: [PHP-DEV] [7.2] Timetable

[Davey Shafik]

As I recall the 7.1.0 release process there was never a time when a
scheduled release didn't have enough changes to warrant it.

I think consistently scheduled releases give us a few things:

- Early access to changes as they progress
- Predictable timelines
- No rush to get a bunch of things in because the next one is only two
weeks away

Additionally, the value of the multiple RCs is that it gives a nice runway
between when breaking changes and new RFCs are allowed in and shoring up
implementations for the release. Ideally, you'd have more Alphas than
Betas, and more Betas and than RCs, but the reality is that until you
freeze for RC, the dust doesn't settle.

I think the current release schedule (or similar) has produced good
results, and see no reason to change it unless we change some of the
semantics. E.g. more Alphas, but no more RFCs after Beta 1, but you're just
shifting the process down the line a bit, it's just names at that point.

- Davey

On Sat, Apr 22, 2017 at 2:05 PM, Anatol Belski  wrote:

>
>
> > -Original Message-
> > From: Nikita Popov [mailto:nikita@gmail.com]
> > Sent: Saturday, April 22, 2017 1:49 PM
> > To: Anatol Belski 
> > Cc: Sara Golemon ; PHP internals <
> internals@lists.php.net>
> > Subject: Re: [PHP-DEV] [7.2] Timetable
> >
> > To clarify, I wasn't referring to our patch release RCs here, I
> certainly see the
> > usefulness of those. What I had in mind is that the current release
> timeline for
> > PHP 7.2 plans one new release (alpha, beta or RC) *every two weeks*
> starting
> > June 8th and continuing for 12 releases. This seems excessive and I
> don't think
> > there are many people who are interested in testing a new release every
> two
> > weeks. At least after the alpha phase the PHP-7.2 branch should be about
> as
> > low-activity as our other release branches (as all features have landed
> by this
> > time), so there will not be a lot of changes between releases two weeks
> apart.
> > This fast-paced release cycle is probably also part of the reason why we
> have to
> > do the beta/RC switch early, as it's pretty hard to take a "beta 9"
> seriously, it's
> > just "yet another beta" at that point.
> >
> >
> > I don't think we'd lose much (actually I suspect that reducing the
> number of
> > releases will increase willingness to test them) if we used a monthly
> release
> > cycle instead (e.g. using 2 alphas, 2 betas and 2 RCs.)
> >
> Ah, I understood it in wrong direction then. For the minor pre cycle,
> probably some release could be omitted, if there's no activity, like we
> currently do with a security branch. AFAIR there was no case like that with
> 7.0, but that's also clear why as it was a major change. Probably would be
> good to hear more impressions from RMs about how it went with other
> branches. The timeline is anyway just a planning, it could be good that
> some beta could replace the planned RC, if there are some issues. Depending
> on impressions others have, probably the process could be indeed slackened
> a bit, needing an RFC and extension to the release process doc. Maybe it
> could be enough to have a release monthly, or more frequent if some urgent
> fixes are to be tested, with the distance of two weeks as minimum.
>
> Not the last factor here is, I can tell, is also that the new RMs have
> more practice on the actual release process. There are several nuances that
> are better to be practiced before it comes to GA.
>
> Regards
>
> Anatol
>

Re: [PHP-DEV] PHP 7.2 Release Managers

[Davey Shafik]

Thanks Remi!

As the Release Process RFC requires two RMs[1], are you and Sara willing to
collaborate as a team for 7.2? If not, you will each have to find a second
team-mate :)

- Davey

[1] https://wiki.php.net/rfc/releaseprocess#release_managers_selection

On Thu, Apr 6, 2017 at 9:44 PM, Remi Collet  wrote:

> Le 28/03/2017 à 16:56, Joe Watkins a écrit :
>
> > Please put your name forward here if you wish to be considered a
> candidate.
>
> After some time thinking about this,
> I choose to apply to the PHP 7.2 RM role.
>
>
>
> Remi.
>
>
>
>

Re: [PHP-DEV] PHP 7.2 Release Managers

[Davey Shafik]

As a reminder, this thread is just for folks to throw their hat in the
ring. There will be a formal vote on the wiki to pick the actual RM
(assuming anyone else volunteers!).

- Davey

P.S.
+1 ;)

On Thu, Mar 30, 2017 at 10:34 AM, Christoph M. Becker 
wrote:

> On 28.03.2017 at 17:11, Sara Golemon wrote:
>
> > On Tue, Mar 28, 2017 at 9:56 AM, Joe Watkins 
> wrote:
> >
> >> Please put your name forward here if you wish to be considered a
> candidate.
> >
> > I keep meaning to have a go at this, and with such inspiring mentors
> > at the ready, there's really no better time than now.
>
> +1
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] ; on the end of the line

[Davey Shafik]

On Wed, Mar 29, 2017 at 11:10 PM, dmitr y  wrote:

> Hello, dear coders.
> I'm using php for a year and it's being my favourite language. Also I'm
> using some bookkeping languages which is based on php syntax but ';' on the
> end of the line is not neccesary on it.
> So I can't understand why syntax needs symbol ';' on the end of every line,
> if it also ends by 0Ch and 0Dh. Is there a possibility to interpretate php
> code without ';' on the end of the line, and make it not necessary?
>
> Maybe some compilation parameter or directive at code?
>
> Best regards,
> Dmitry
>

Dmitry,

It is not necessary to end each line with a semicolon (the ';'), it is
however necessary to terminate each statement (or instruction) with one.
It's very common to only have one statement per line; which is why is seems
that it is required on every line.

There are several places this is not the case:

- Any block opening/close: e.g.

if/while/for/foreach ... {
   // or it's close, or a comment for that matter!
}

- An unfinished statement:

echo $foo .
 $bar // concat (.) operator can be here, as above, or on the next
line:
 . $baz; // only semicolon here, to finish the statement

- Preceding a closing PHP tag (?>) as this also terminates a statement:

echo $foo ?>



Alternatively, you may have MORE than one statement per line:

- echo $foo; return $bar;

- syslog(LOG_ERR, "Something went wrong!"); exit;

- header("Location: /foo/bar"); exit;

Notice each of these has two statements. (Note: I don't think any of these
are particularly good ways to write readable code, but they are all
syntactically valid code).

While I know some languages make semicolons optional (javascript), or omit
them entirely (python),  semicolons in PHP will not be going away (or
optional) any time soon.

Even a language like Go where they are optional, and largely discouraged,
it can be used to explicitly allow the initialization of a local (only
exists in the scope of the if statement) variable prior to the condition:

if err := DoSomething(); err != nil {
// initialization before; condition {
  return err // no semicolon necessary
}

I hope this helps!

- Davey

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

[Davey Shafik]

I personally think there is value in marking strings as binary using the
'b' even if PHP currently doesn't differentiate, from a developer
friendliness perspective. It shows intent, and informs the reader of what
to expect if they inspect the value.

If anything, the only change I'd make, if possible, would be for var_dump()
to print it in a readable format (e.g. hex encoded) by default.

I don't see any issues with forward compatibility either, any attempt to
re-add a 'b' later would exhibit the same behavior it does now, most likely.

- Davey

On Thu, Feb 16, 2017 at 2:36 PM, Pedro Magalhães  wrote:

> >
> >
> > Too bad it has been rejected.
> >
>
> The vote is still open until the 20th.
>
> Regards,
> Pedro
>

Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

[Davey Shafik]

On Mon, Jan 9, 2017 at 10:43 AM, Paul Jones  wrote:

>
> > On Jan 7, 2017, at 15:41, Joe Watkins  wrote:
> >
> > That doesn't sound like a positive consensus that this is a good idea,
> it is rather the opposite.
>
> Not to get into interpretations of comments, but while I agree that there
> were one or two actual negatives, they were predicated on a
> misunderstanding of the purpose of the RFC. As such I took them as neutral,
> rather than negative. The remainder were questions or comments, and not
> negative ones.
>
> Either way, I think we can see from reactions here since then (and
> elsewhere) that there is some level of positive interest in the RFC as
> presented, as well as some healthy technical questioning. I'm happy to hear
> both.


[Trying again, Sorry Paul who has likely received this three+ times nows]

[Resent without URLs, grrr]

Let me be absolutely clear:

Any attempt to improve HTTP request/response handling in PHP that doesn't
take into account WebSockets or HTTP/2 Server Push is a non-starter for me.

PSR-7 was heavily influenced by Python's WSGI spec and they are also seeing
it's inability to handle these types of interactions. As such there is a
new recommendation being proposed called ASGI: Asynchronous Server Gateway
Interface [1], that is intended to address this.

I think it would be more beneficial for PHP the language to consider
reaching out to the Python community and seeing if it makes sense to
collaborate on this. A new ASGI SAPI would come with message
objects/interfaces (see [1]) baked in.

If we want PHP to have a meaningful presence for the future web, we need to
move forward from our current request/response 1:1 HTTP-only model.

So, as currently proposed, I'm -1. It doesn't move the language forward in
any meaningful way.

- Davey

[1] google: ASGI python, it's the first result

Re: [PHP-DEV] PHP 5.6 end of active support

[Davey Shafik]

On Wed, Dec 14, 2016 at 7:15 AM, Dennis Clarke 
wrote:

> On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:
>
>> Hi
>>
>> On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:
>>
>>>
>>> Hi!
>>>
>>> The end of active support for PHP 5.6 is documented to be on December,
>>> 31th[1].  Does that mean that there'll be no further release with
>>> "normal" bug fixes (but only security fixes)?
>>>
>>
>> Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc
>>
>>
> This is entirely too soon. At the present moment neither of the PHP 7.0
> releases will compile clean on a strict POSIX environment. At all. The
> version 5.6.x tree is perfectly stable and works out of the box without
> an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
> compile. I guess I need to file more bug reports and push through this
> or the 5.6.x version will be dropped with no valid replacement that
> works in a strict environment.  Perhaps the gcc compiler is an absolute
> requirement and if that is true then the code isn't acceptable to any
> other compiler regardless if it is C99 compliant or otherwise.


PHP 5.6 isn't EOL for a further two years, you should be fine.

- Davey

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

[Davey Shafik]

On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette 
wrote:

>
>
> On 12/12/2016 01:16 AM, Silvio Marijić wrote:
> > This have occurred to me also, I wanted to separate that into two RFC's,
> > but then how we deal with RFC's that depend on each other?
> well that's just my opinion but I don't think they depend on each other,
> this rfc seems useful on its own. The "clone" one might depends on this
> one but it does not *need* to either (otoh it certainly would be much
> more useful with immutable classes than mutable classes)
>
> plus, this part might already trigger enough discussion and adding
> everything at once might get confusion. I can think of : clone, late
> initialization, DateTimeImmutable and probably other subjects that could
> make the discussion noisy
>
> I'm not as familiar as you are with this mailing list so I might very
> well be wrong too ^^
> >
> > 2016-12-12 1:03 GMT+01:00 Larry Garfield :
> >
> >> Assuming this was intended for the list...
> it was, thank you
> >>
> >> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
> >>
> >>> Currently the only "unlocked context" for an object is its
> >>> constructor.  As discussed previously, that is insufficient.  For any
> >>> non-trivial object (more than 1-3 internal properties) creating a new
> >>> one via the constructor only when incrementally building is
> >>> prohibitively difficult.  The pattern of with*() methods that spawn
> >>> new objects via clone(), a la PSR-7, needs to be supported.  That is:
> >>>
> >>> immutable class Money {
> >>>// ...
> >>>
> >>>public function add(Money $other) : Money {
> >>>  $new = clone($this);
> >>>  $new->amount += $other->amount;
> >>>  return $new;
> >>>}
> >>> }
> >>>
> >>> I'm not sure how easily we can denote that sort of case.  It's outside
> >>> the __clone() function itself, which is what makes it difficult.
> >>> Without that, though, such immutable objects are of only limited use.
> >>>
> >>
> >>
> >>> As you said, it has been already been discussed that a method to build
> >>> new altered object from an existing one could be improved. Different
> >>> options were proposed but maybe it's better to start small to get this
> >>> first part right and add this in another rfc ? having everything at the
> >>> same time might makes the rfc more difficult to be accepted
> >>>
> >> On the contrary, an RFC that doesn't fully solve the issue at hand and
> >> leaves major gaps in place is a poor RFC, and I would expect to be
> >> justifiably voted down.
>

I wonder if we can essentially make all public methods act like they are
static (no access to $this) and then use something like:

immutable class Foo {
 protected $bar;
 public function getBar() with (Foo $instance): string // $instance is
a clone of $this
 {
   // context == $instance, so access to private/protected
   return $instance->bar;
 }

public function withBar($bar) with (Foo $instance): Foo
{
 $instance->bar = $bar; // Allowed as we're in scope
 return $instance;
}
}

Only operations in the scope of the class itself (and it's descendants,
adhering to standard visibility rules) can make changes on the cloned
variant. The `with ($instance)` is optional, $instance is just a variable
name. In reality you'll want to use it most of the time I imagine.

I suppose you can re-use the `use` keyword here too.

Also, this shouldn't allow for immutable properties.

Another option is to look at the way that HHVM does immutable types, though
that is _file_ based.

- Davey

Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

[Davey Shafik]

This issue is not difficult to solve in userland, at least well enough for
debugging in my experience. Here's an older example I wrote up on my blog
that worked (but I'm told is broken right now):
https://daveyshafik.com/archives/605-debugging-pdo-prepared-statements.html

Thanks,

- Davey

On Mon, Dec 5, 2016 at 10:30 AM, Adam Baratz  wrote:

> >
> > Could you please explain what's the use case? As far as I'm concerned
> >> such information would only be useful during PDO driver development,
> >> phpt files and bug reporting / fixing.
> >>
> >
> > It's pretty simple : debugging and optimizing scripts and statements.
> I've
> > lost hours, manually emulating tons of statements, or trying to guess
> > what's happening when I have something like 1000+ prepared values (mass
> > insert). And since I have to do it by hand, mistakes happen, so I lose
> even
> > more time debugging my emulations. Having a direct access to the emulated
> > statements, without having to dirtily parse a dump, will be a huge plus
> for
> > me, my team and the performances of my debug component.
>
>
> I understand the use case -- I submitted the "v1" RFC, after all -- but the
> discussion for the last RFC seemed to stall at an "agree to disagree"
> stage. My hope with "v2" is that it'll be favored more than the first one,
> which basically squeezed past the required margin for acceptance.
>
> That said, do you have thoughts on a third approach? It might be that we
> should do what Matteo suggested earlier in this thread: make something more
> robust for getting structured data out of statements. To be honest, the v2
> RFC does exactly what I need. It'll let me write .phpt tests and do one-off
> debugging.
>
> But if your take is that simply that you prefer v1 over v2, the regular
> vote should cover that.
>
> Thanks,
> Adam
>

Re: [PHP-DEV] php.net mailing setup owner?

[Davey Shafik]

On Thu, Dec 1, 2016 at 2:48 PM, Rasmus Lerdorf  wrote:

> On Thu, Dec 1, 2016 at 8:00 AM, Derick Rethans  wrote:
> >
> > I think it's time to retire Ecelerity. Nobody knows how it works. if
> > It'd be postfix, I would likely have checked one of these ghost mail
> > reports out...
> >
>
> I don't think anyone disagrees with that, but at the same time it is a lot
> of work to switch and get a secure and efficient anti-spam mail server
> working well these days.


I'm going to assume that outsourcing it (with sponsorship?) is out of the
question?

Re: [PHP-DEV] PHP 7.1.0 GA

[Davey Shafik]

On Wed, Nov 23, 2016 at 9:12 AM, David Zuelke  wrote:

> On 22.11.2016, at 19:36, Joe Watkins  wrote:
>
> > Evening internals,
> >
> > I'm excited to announce that PHP 7.1.0 will be GA on December 1st.
> >
> > It has taken a lot of hard work from a lot of people, so stop whatever
> you
> > are doing and give those people a round of applause.
> >
> > Cheers
> > Joe
>
> Good stuff. A++, would use again :)
>
> Does it make sense to delay 7.1.1 by a week so its release cycle syncs up
> with that of 5.6 and 7.0? They're due on January 5, while 7.1.1 would be
> due Dec 28 right now.


I'd say so, yes. It will be necessary to sync at some point for security
issues.

- Davey

Re: [PHP-DEV] DateTime microseconds discussion

[Davey Shafik]

On Tue, Nov 8, 2016 at 6:28 AM, Alice Wonder  wrote:

> On 11/08/2016 04:16 AM, Arjen Schol wrote:
>
>> Hi Dan,
>>
>> I think you make some bad assumptions here. The examples provided by
>> Sjon are scripts submitted to 3v4l.org They may have bad assumptions,
>> but are real life examples of DateTime usage. And they will break.
>>
>
> They are already broken. That's the point.
>
> Rarely will the current breakage trigger but it will trigger.
>
> Personally I prefer it when bad code obviously triggers, it can be very
> difficult (read expensive) to track bugs in code that only rarely and
> randomly trigger.


I have discussed this with Joe, and we are OK with the warning BC break;
everything else is not considered a BC break.

We should definitely document some best practices around relative dates,
e.g. using midnight, or explicitly setting the time.

Thanks,

- Davey

Re: [PHP-DEV] [RFC] Convert numeric keys in object/array casts

[Davey Shafik]

This has been the case since 4.3 at the least: https://3v4l.org/bjZ4d
On Sat, Oct 22, 2016 at 22:48 Yasuo Ohgaki  wrote:

> On Sun, Oct 23, 2016 at 4:59 AM, Yasuo Ohgaki  wrote:
> > Numeric key name must be string?
> >
> > $obj->{'0'} = 1;
> >
> > or could be like (Without quotes)
> >
> > $obj->{0} = 1;
>
> It seems variables can be numeric now.
>
> https://3v4l.org/bjZ4d
>
> 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] PHP-7.1.0RC4

[Davey Shafik]

Thanks Joe!

- Davey

On Wed, Oct 19, 2016 at 3:48 AM, Joe Watkins  wrote:

> Morning internals, QA folks,
>
> I would like to announce the availability of PHP-7.1.0RC4.
>
> Downloads: http://downloads.php.net/~krakjoe/
>
> php-7.1.0RC4.tar.bz2
> SHA256 hash:
> ed2ef6dec04d1f8745b6212c55684cfd1350fad28db4c659ff99e9c6d16d3f36
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJYB0z4AAoJEJZAoYTDlTxVvbsP/RM9VO8U7LABB4F3lWbmo0wW
> riCmURs82XUK4x+C+Bq16vpro+cJGISSCaD5YZpWd53DONm0JaB6jWKdw/2aQfVc
> Whjd9D+WYL4JgTfJNQgOcIFfTx0fpQnVe0OwT5DqwPrlzHRt3Ek6zeBkXtXtzJM/
> eibyFtkK2E7c8NojBgUb64PwHu8e+EjGiMg5m0eiqIZc9Ogg/Fq11/piLkPy3U8A
> J+DfoAJhArsNfTWpv87pJhg377yQkapxqYEfpFKGGS+/qA29hqYEwnNnEoXUyuRF
> vfs5l56XWexcmOQQA8k9XdTs87+pMoC2GsgtCWxU9HGu/bqseHoeylsXAAz84veL
> ePJsZyyf+MK/ksOEBlaMrjct3MEDS7wMKWk2Oqym5po/sdnA+XiKb0l1UNkNTbcp
> HqXL9U94QV/NsRDlmboQ/NilYqr3k4YoqMMWYJdqIsmYm5ldTQem+rvuUno8nx8a
> byYvdUXXrbbM+hmKX8gGqV0ERfRLUU44xByTqpftJPVTsaisdkTY1hzRwJKTkZOI
> gzm9czciPJOUdVuMJEt+tw+wyI6IGcVMFwjVk6Nf2voTtP1t5b9NXR6u/9dMDgJm
> bfqbV4ffIMBG7Rf9ggELmcBeK4brfBFSwJYZuoQl7QJprYH/jTbSnkSQ/lkOQDLv
> xG9ppUCWmSViKJUzHYLw
> =txIc
> -END PGP SIGNATURE-
>
>
> php-7.1.0RC4.tar.gz
> SHA256 hash:
> 8701d826d210abaa0d54d9a8344d14f00f1fb34d918b14e61f4fdd1b19226c46
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJYB0z8AAoJEJZAoYTDlTxVcZUP/3Ot1CVledtqVcsLCLrPnWBj
> KxPH999OJy7gwuXQsCHF5QfwZGU1lrc/y9wAIHkaB26FANnkOujhHV6tcMqc03N0
> tI26YklI0bZJJ0FDGgh+GH5vQL6Tx5Dxy1KfMB/2BTi0+rjwS5L1qfN8fX4DhWjQ
> 1TeMkeM+tAkjIlPGoUWzvqzo/n21ANnHwLspQxQgG/+lW8b61UBD00jtXY9XByNS
> pCG8q1ebKb+jBMa8fuPdRsxbDOsdqQzPhwIehO6sWy8P+NpdXjwR7+UmO5Wh2EZw
> jyiv4Xll4z3rj6X2AVdeVirUv464HQpBFdqZLVu3L4RMx5o6UbLep1nw5DQjpWoZ
> PPQzWcGr5DcuTG4d399wC93ti04tmksjOfrLazdAVcJ8zjXpJYYuFlg3kbJnMpqw
> a+6pkPtMQIsbAu6Kgc4e+fQmsEIlwjCFhRAA7WDPF+nxuHnun1QnrpsPAZGeQqau
> PMj419dxk26NmVKedlofBdn+X9GEJItIaVyHwy1x80qo+yYtJaokzMdnMg6C+KwF
> /Zxi5VYzdSAnZX3tSs5BTQ3HzzFC5S3P6UwD8dDZA/ADETxo2vhJyANMFuvGwAH/
> uTGjqfi30q3naDFwBbKUeNinLCIR5B8D1ryJy0F1kOIB8rpclFS9UuplCZQ5ie5M
> wbP2tQWvhFfuyXoPvfEL
> =8IdV
> -END PGP SIGNATURE-
>
>
> php-7.1.0RC4.tar.xz
> SHA256 hash:
> aa06af4cd4674b4a57969d39566497d700c291f433209f8c83b75ffc1128d258
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCAAGBQJYB00AAAoJEJZAoYTDlTxVcW0P/0FH00FnGMvIUBfkmyPVu6Lh
> KeeW9G2Zudy1IXjmjtYJLeQn0ese0aHEHhBgSF83Ukje00QQgI/MGVBF4T05zS8M
> agLbqzgHwaKEdZpPBpSrhD8UWJN47F8evti5NtyZmq6VGdNEEwyNgf82sjIn7Hxy
> gYJAIRxi7DbGSfff0QQndVl1hkFsvDtjFRHxbymloTwb5edbntYSQxGJJWSg6SXj
> TvD85dEI1VP8zznq5CTQFrJVF+YdU7FUIq9Gs4ATKIFqHEzbyRDWC34OF2Au+shW
> eboi0ELDR3G4Jf0z1/hBb8i+ovhSOWSmGC/BtESGqF2QGqeoncZwGNGtAoecVZHF
> Fok+XVIxSwGFG2Ang7F7rWGCWpqS9PEeQQgrDfuSFER462Ke5tBiFDHvdc2Mm+tZ
> dXQsE80TcWxOTFaDGNVt4exwkMW+pIqZPRhr+L4H5XeDsgJWgmHF4OWyZ8h2MzoD
> 0Qy0Q1vkuV3f52dR+Sc2ySgZ+3+wTOy99omxi9sMcWJDf71EGKVyasBbWXxtd1NK
> KHOfdWSTZSeEgG1doSEQVuyYv41m0R4fPE4+w1SIxC9bfmzRtwn71cHckco6Qaua
> hv1y6EnbhS2fBjWRIsKrS8HtWu30+IGlBdSflmRnXPH/pzpEB8CEqzPvd//fhubo
> Gxnx7odid2/98tvjh3Vg
> =YB0l
> -END PGP SIGNATURE-
>
> Please see NEWS and UPGRADING for recent changes.
>
> Sorry about the delay.
>
> Cheers
> Joe
>

Re: [PHP-DEV] Re: Fixing insane session_start() behaviors

[Davey Shafik]

On Tue, Oct 18, 2016 at 11:08 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > I pushed patch fixes number of nonsense/inconsistent session function
> > behaviors. The additional patch is pushed so that it's easy to cherry
> > pick minimum fixes. The last push is the additional fixes.
>
> These changes look like a reasonable cleanup. I'm not a big fan of
> zend_parse_parameters_none additions, since I don't see any useful
> function for them, but they don't hurt either. I left some notes on the
> patch though, please look there.
>
> I'm not sure about 7.1 - while I don't see anything that would break any
> reasonable code, except issues noted on the pull, the patch is pretty
> big and I might have missed something. I guess it's for RM to decide. No
> objection for 7.2.
>
> I notice that most test changes deal with scenarios that were covered
> before, are there tests that test the new things - the scenarios for
> which handling has changed? I couldn't find tests for some cases, like
> INI modification, would be nice to add them.
>
> Also, a reminder that you'd have to update all the documentation in the
> manual to reflect the change in the return values. And UPGRADING too.


> I was planning to fix session_start() behaviors by PHP 7.1, but I
> forgot to do this completely. Partial fix is merged currently.

Yasuo, assuming "partial fix" doesn't mean "broken fix" but instead "it
doesn't do everything I planned" then I do not want this in 7.1. As others
have pointed out, it's not a small change and sessions are a fundamental
part of PHP — we are simply too far into the release cycle to include this.

Please target 7.2/master.

Thanks,

- Davey

Re: [PHP-DEV] [!] Master merged into PHP-7.1

[Davey Shafik]

On Thu, Oct 13, 2016 at 12:20 PM, Lauri Kenttä <lauri.ken...@gmail.com>
wrote:

> On 2016-10-13 20:16, Davey Shafik wrote:
>
>> Can anyone shed some light on:
>>
>> 1) when it was merged
>> 2) who merged it
>> 3) how the dates are messed up
>>
>
>
> 1) and 2)
>
> commit fb92482c8ad1e35b82c4d7b758ae0f1f5ecd4929
> Merge: b0cacee 4b8bdac
> Author: Joe Watkins <krak...@php.net>
> Date:   Mon Oct 10 12:17:11 2016 +0100
>
> Merge branch 'PHP-7.1' of https://github.com/php/php-src into PHP-7.1


How did you figure that out? :D

Thanks for this :)

- Davey

[PHP-DEV] [!] Master merged into PHP-7.1

[Davey Shafik]

Hey folks,

I have a bit of a mystery on my hands.

Yasuo brought to my attention last night that it looked like someone had
merged master into the PHP-7.1 branch, and indeed when Joe and I tried to
build today that was the case.

Proof: https://github.com/php/php-src/blob/PHP-7.1/main/php_version.h

Now, I used `git when-merged`[1] to figure out when it was merged and came
up with the following commit:

commit 4a3188f0935211332cc3a545673e882331b14504
Merge: dc9ae10 f41b69e
Author: Yasuo Ohgaki <yohg...@php.net>
Date:   Wed Aug 10 09:39:17 2016 +0900

However, the date on it is Aug 10, and I have video proof from Aug ~29th
(RC1 build) that it wasn't there then. My local PHP-7.1 branch also does
not have this commit, and it's last commit was:

commit 50059639c86a10fe11d6ec3eec2e690ee77afccc
Author: Davey Shafik <m...@daveyshafik.com>
Date:   Wed Oct 5 13:07:47 2016 -0700

So that means it was merged in the last 8 days.

Can anyone shed some light on:

1) when it was merged
2) who merged it
3) how the dates are messed up
4) how to fix it

Also: at this point, I'd like to ask for NO FURTHER COMMITS TO THE 7.1
BRANCH while this is sorted out.

Thanks all,

- Davey



[1] https://github.com/mhagger/git-when-merged

Re: [PHP-DEV] OpenSSL ext status including port to OpenSSL 1.1

[Davey Shafik]

Remi,

I'm glad this was followed up on, it is likely the source of a reported
issue!

7.1 no longer supports LibreSSL due to the usage of some new openssl
changes, you can find the errors http://awel.domblogger.
net/7/php7/ssl_error.txt and a patch by the reporter here:
http://awel.domblogger.net/7/php7/php-7.1.0RC3-libressl.patch.txt

Can you review the patch and apply it for RC4? It should just use the older
library (compatible) behavior.

Thanks,

- Davey

On Tue, Oct 11, 2016 at 4:57 AM, Remi Collet  wrote:

> Le 11/10/2016 à 12:56, Remi Collet a écrit :
> > Le 20/03/2016 à 20:50, Jakub Zelenka a écrit :
> >> Hi,
> >>
> >> I just wanted to send a quick update about my recent work on openssl
> ext in
> >
> > Can you please update the state of openssl 1.1.0 compatibility ?
> >
> > I see most work done in master ?
> > Not in 7.0 or 7.1 ?
>
> In fact, 7.1 is OK, so I will update Fedora repo to 7.1.0RC4 very soon.
>
>
> Remi.
>
>
>

Re: [PHP-DEV] Regression between RC1 and RC2?

[Davey Shafik]

Yes, we should not mask the exception. The behavior in 7.0/7.1.0RC1 is much
better IMO.

(As seen here: https://3v4l.org/EJpD4#v700)

- Davey

On Fri, Oct 7, 2016 at 12:52 PM, Nikita Popov  wrote:

> On Fri, Oct 7, 2016 at 9:31 PM, Derick Rethans  wrote:
>
> > Hi,
> >
> > I was looking at Xdebug for PHP 7.1, and I ran into the following
> > inconsistency:
> >
> > https://3v4l.org/tHteN
> >
> > I first thought that Xdebug was messing up, but it seems like it's
> > different behaviour in PHP itself. As I clearly return an array from
> > __debugInfo, I don't think the new result is the correct one.
> >
> > cheers,
> > Derick
> >
>
> This is due to https://github.com/php/php-src/commit/
> 2d8ab51576695630a7471ff829cc5ea10becdc0f, which landed in PHP-7.0 as well.
> The problem is that __debugInfo currently is not able to handle exceptions
> gracefully. I think we should revert this change for now as it hides the
> fact that the underlying cause of the error is an exception.
>
> Nikita
>

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

[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] [RFC][DISCUSSION] Improve uniqid() uniqueness

[Davey Shafik]

On Sunday, October 2, 2016, Yasuo Ohgaki  wrote:

> Hi all,
>
> On Mon, Oct 3, 2016 at 3:56 AM, Yasuo Ohgaki  wrote:
> > Besides improving "more entropy" the default and data, I prepared
> > fully compatible patch to simplify discussion.
> >
> > https://gist.github.com/anonymous/fb615df325d559fa806a265031a06ede
> >
> > I would like to apply this patch from PHP 7.0 branch, then discuss what
> > the default should be.
> >
> > Any comments?
> > If there is no objections, I'll apply this few days later.
>

Yasuo,

This change should go through the standard RFC process and should be
targeted at 7.2+ (master) *only*.

Please check with the RMs before merging functionality changes into release
branches. All functionality changes need consent and consensus. Bug fixes
(that don't change functionality or break BC) do not.

I understand your desire to fix these things, especially the security
related type stuff, but as a group we have a responsibility to create
predictable, sane, and safe (as in, don't break stuff) migration paths when
we can. A history of doing this is WHY php is still going strong after so
long.

Thanks,

- Davey

[PHP-DEV] PHP 7.1.0RC3 is available for testing

[Davey Shafik]

Hi,

PHP 7.1.0RC3 was just released and can be downloaded from:

https://downloads.php.net/~davey/

The Windows binaries are available at

http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please refer
to the NEWS file:

https://github.com/php/php-src/blob/php-7.1.0RC3/NEWS

Please test it carefully, and report any bugs in the bug system.

The fourth release candidate is planned for October 13th.

Below is the verification information for the downloads:

php-7.1.0RC3.tar.bz2
SHA256 hash:
127b630939761cd48d2b4bc467ac299e2466c19bc9c673270608900aebb5635e
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX7Hn7AAoJEGWqzKLMO04mjO4IAJr9qnUuZrV1mt0TbfRXGa6g
v5gRvHT892/rDxe9RdEUE2nSJ6LxfhuMz4soZrfnmgmU5+VVVfsrJCYe3M+FH4AU
oS4F/pjluMzClMkYTM54KK3qO4SaocEvVo0h256VOLTy/sjZzZSHvzAHoRm/BIfS
AzfEgT2073aB3SNYqiqudpSrs0tKOy8v20cXXzI+OGe9oOx6Y245FL08IsVRU/hA
Yw6X/pjJON6qpobT8kt6reZ+yZd3rU8ICk46KM2lfAXNLkaNT/o3wYEsQVuDoGqi
YM+LHiTWbJwQ9sGlxKqT83cA1Z9cktsMviSLIGCOlcjxQ8WqYRcAzGOPR2aoMtw=
=tirP
-END PGP SIGNATURE-


php-7.1.0RC3.tar.gz
SHA256 hash:
7f100e02f62cdb2909c1c32cc41316cbdbca9dfcbb0b7c0bd3968b6da10e0721
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX7HoHAAoJEGWqzKLMO04mzzMIAI1zdTRKRfrqn3paP6zPvhxA
JwB6nuzxZjtDQ+tbiPWdei61/Ovex8VUBJPhcHrQDPIRdMkm7HGQhtOolFLE5Sj4
oR8/MfUOdbi0OFITOQjjpPd5mG+bWofaH/qTpKX+2isn482eJwo+2a0nkgIgqc8f
cKbBktocQ8PeQNQGf94moYPUEnThztKEhwBhZeeN44F8v3DraaFTT6+u8WVYgERp
Kajy03sMDdFLwf77oIqdSRFcuggMSIWwDQlh/gf1pMZknKNRy0c8g/VEZS147Snu
k1ICrx0smn9nHgR1o1m1BH6dxuwSodm57bInk0oPWc2yFXKamjIjsR9kKqQe89k=
=GKaG
-END PGP SIGNATURE-


php-7.1.0RC3.tar.xz
SHA256 hash:
6a824c913ac30494acd721a2efe51689c5ed6b1e621a11c6c1c0c8811fb8
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX7HoIAAoJEGWqzKLMO04mMfEH/3AVIeP3JHzs8m4h2v5NpX+C
rNu076lp2SkKPqFaeJIRgAEfeN4bbm0QabIclpmX21YkfbyQ6P8LE7Kv9r/oiwKm
DG9kAvl/5+Qa3NwnUn9+6srfjTd6jBQijkXoGkNTjKNpXJu3vmDRY+tSKBRKhgpq
imtnACvR5HDan4YF4j29d6QUP6wv1SecKCf/vgND+K4/6YkFwsiwmkN6Fi5cPQZs
I6l7E3K240QLCBZw2o5jzH4l/72YKX+nvsWpV5cA1IAC8GERYtH+UQ+XVBvbLsoh
Q4H2LiveGctCvT/NR+puUC9dcVdXuYcaZ5m2GWF0Ga4uuFHx8QG2lsITCi9GUBE=
=B19b
-END PGP SIGNATURE-

[PHP-DEV] [RFC] [FAILED] Add PHP Engine Identifier Constant

[Davey Shafik]

Hey all,

Just a quick note (a couple of days late, sorry) that the vote for the RFC
" Add PHP Engine Identifier Constant" failed, 8 to 9.

I'll consider this RFC closed at this point.

Thanks all!

- Davey

Re: [PHP-DEV] Server-Side Request/Response Objects

[Davey Shafik]

On Mon, Sep 26, 2016 at 2:32 PM, Rowan Collins 
wrote:

> On 26/09/2016 20:37, Paul Jones wrote:
>
>> tl;dr: Gauging interest in an extension for server-side PHP request and
>> response objects (*not*  HTTP messages per se; see below) prior to writing
>> an RFC for them on the wiki.
>>
>
> This sounds like an interesting project, but I have a few questions.
>
> First, the obvious one: why does this need to be an extension and/or built
> into core? Are there reasons such as performance for implementing this in C
> rather than PHP? Does it provide functionality that is hard to implement in
> a userland library?
>
> You mention that it is not just an HTTP wrapper, but although you mention
> researching other frameworks, I can't see any reference to PSR-7 [
> http://www.php-fig.org/psr/psr-7/]. What do you see as the relationship
> between your proposal and that standardisation effort?
>
> Regarding the design of the objects themselves, why is stdRequest
> property-only, but stdResponse method-only? The asymmetry feels awkward to
> me.
>
> I think the most interesting parts are those that attempt to rationalise
> $_SERVER, and I think a library (or built-in functionality) devoted to
> those could be very useful. Some of that overlaps with PSR-7, but that
> standard doesn't go into depth on things like Accept headers,
> Authentication, etc.
>
> Like I say, it's an interesting idea, but I'm not sure how it fits in with
> the wider ecosystem.


Additionally to this, we need to start thinking about what it means to move
away from simple request/response architectures. In the age of WebSockets
and HTTP/2 multiplexing w/Server Push, the likelihood of multiple responses
for one request, or even responses with no associated request, are possible.

I'd rather look at this as the target for this kind of exploration and
implementation.

- Davey

[PHP-DEV] PHP 7.1.0RC2 is available for testing

[Davey Shafik]

Hi,

The first release candidate for PHP 7.1.0, RC2 was just released and can be
downloaded from:

https://downloads.php.net/~davey/

The Windows binaries are available at

http://windows.php.net/qa/

For the list of bug fixes and other changes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-7.1.0RC2/NEWS

Please test it carefully, and report any bugs in the bug system.

The next RC release, RC3, is planned for September 29th.

Below is the verification information for the downloads:

php-7.1.0RC2.tar.bz2
SHA256 hash: 27f2a8a6268e787a96fafd75591c8934a4ac602f3bbfcfeba493bab6a6ef
b430
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2UGxAAoJEGWqzKLMO04mQ+IH/06SUdp9y5dvT7szXoaUkzto
v/i7XhqG1ynsytmp5np3vzHvHIBPFEWa31oZ84qTIY7HiZrF705xKmNQcvGVT/CQ
2umPJLyAnl7T5HXH0qg+e509wr38rayNZNAqU/i1RoH1zNdUj3/AbkKZX+dVMdTl
FSGFkrRaAE3nb0ZV+fv+StMiNU9VY9vtUwUjENE171m9/spCTSz0jOV1y5ET5+b5
NJjDTa2Tz4r76qyPsTZHj5Cho8oKidLv/BE4o6/5zcj0pTq+ZHwtXT9Uz6d9LhRM
VRtEp2fxAnqgQ7XbBf1zDcsdNzBEtEDxkB2LIFY6zxjb5mtc+xwKEDrobEM2LHY=
=bI4k
-END PGP SIGNATURE-


php-7.1.0RC2.tar.gz
SHA256 hash: 05a24977d633dffda6a65c301f3113adf4f100372a0453867d9cf9d4dde4
0231
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2UHVAAoJEGWqzKLMO04mT4gH/3R7A2xW17x5LLBNpMuxBhmF
1223Jcuk4A5PvtBTLBVsLgK2z3iOCQQcCfSOwJVhMNR2czWlbrnSJNzh0eXDOlXi
FAhbswV+zmCvhYRnhF0VyC8vH8gSAdcSda344Ifdw3MN+p4rRi7ZvkvubOGo/Cdt
4njZpG5XYGaDHpS1X7Y0kNDmIejMSL8qyAsoK+a/iNyLWI4TdS7kPt4CGnMPYnNS
VeCdIzaSGAKdJkgct82nyVjjyDGmgkHZ9w8SSffeNxhnGky8NVlLPqBtqI9fzDI0
6bN3RVc6ja2CxLe/mfxEmCOeMVKo+ZTbzBLex9hG52DohwvexsJCLlLcHBIXSk0=
=U6hd
-END PGP SIGNATURE-


php-7.1.0RC2.tar.xz
SHA256 hash: 76a00c9d18b9087aee8341ec185269fc53db34c17fb6bd14b69bd653cd4e
c39d
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJX2UHXAAoJEGWqzKLMO04mTFwIAL59bEVg7CfLCqR1nnEG78fl
VAIKqLRKOICSo90rzhimc+ZsaLJ8/zVeZhpAG4flUcM1fCbv9NPJL7aSH4quLOQ5
mQBFzsEwKCSigsQQLr77XK16Woppxc60/TXvv3j0Znn5xZIuBr45FZS6ag0V8587
ZCHJ/xMCp1YfFgb2M+BFUg291P2MHZH3X7MbPyjAJQkRrrg/dJus2od2AELFjhJ5
og1RqbtK72aRXa958OvA+QAVMFiuoo6RvBAmUs1AjRp/MF+FrKDNZskTklV8D1aD
28Zj8QGtUrpk8ADNrPUs2zdm2m/g1j0Ri3pLfyw4zh/EXwDX/HMrmDzrY37ezfE=
=oN3U
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

[Davey Shafik]

On Fri, Sep 9, 2016 at 6:09 PM, Davey Shafik <da...@php.net> wrote:

> On Fri, Sep 9, 2016 at 6:05 PM, Stanislav Malyshev <smalys...@gmail.com>
> wrote:
>
>> Hi!
>>
>> > As noted last week, I'm now opening up the vote for adding a PHP Engine
>> > Identifier constant to PHP 7.2+ (and more importantly, to the language
>> > spec). Additionally, there is a second vote to add corresponding
>> > PHP_ENGINE_(*_)VERSION(_ID) constants.
>> >
>> > https://wiki.php.net/rfc/php_engine_constant
>>
>> Somehow, you made it possible to vote both yes and no at the same time :)
>
>
> Uh… wow. Lemme see if I can fix that without breaking the votes.
>
> Also, you only voted on the second vote. Was that intentional?
>

Fixed, no voting was lost/changed.

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

[Davey Shafik]

On Fri, Sep 9, 2016 at 6:05 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > As noted last week, I'm now opening up the vote for adding a PHP Engine
> > Identifier constant to PHP 7.2+ (and more importantly, to the language
> > spec). Additionally, there is a second vote to add corresponding
> > PHP_ENGINE_(*_)VERSION(_ID) constants.
> >
> > https://wiki.php.net/rfc/php_engine_constant
>
> Somehow, you made it possible to vote both yes and no at the same time :)


Uh… wow. Lemme see if I can fix that without breaking the votes.

Also, you only voted on the second vote. Was that intentional?

Re: [PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

[Davey Shafik]

Kalle,

My use case is for the php7-mysql-shim, some of the error messages I
duplicate and therefore have tests for, are different on HHVM, meaning the
tests fail.

The messages aren't in the spec, so they're not failing to support the
spec, and it's unlikely to affect functionality — which is why I simply
skip the tests on HHVM.

This detection is much harder in Hippy, and who knows what other existing
and future engines.

Also, what happens when we get engines that are good candidates for say,
multithreading, and we want to change application behavior on that engine
automatically.

There are tons of places this _may_ be useful, and there's zero impact to
adding it.

- Davey

On Fri, Sep 9, 2016 at 5:42 PM, Kalle Sommer Nielsen <ka...@php.net> wrote:

> Hi Davey
>
> 2016-09-10 1:49 GMT+02:00 Davey Shafik <da...@php.net>:
> > Hi all,
> >
> > As noted last week, I'm now opening up the vote for adding a PHP Engine
> > Identifier constant to PHP 7.2+ (and more importantly, to the language
> > spec). Additionally, there is a second vote to add corresponding
> > PHP_ENGINE_(*_)VERSION(_ID) constants.
>
> While I understand the reasoning behind it, I do not think that it is
> our problem to solve, whether we do if(defined('HHVM_VERSION')) or
> if(PHP_ENGINE == 'hhvm') seems irrelevant to me. If code are not
> compliant with the spec, then it should be that implementors
> responsibility to make sure that it is resolved imho.
>
> I do not have anything against HHVM or alternative implementations of
> PHP, it rocks, but I think we need to look in other directions, as it
> shouldn't be needed at all to check for what runs your PHP, it should
> _just_ work. For syntax incompatibility, then we can't even filter out
> other implementations with a constant thats executed at runtime
> either, not that I believe it is a major issue, but it is something to
> consider too.
>
> Hence my -1
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

[PHP-DEV] [RFC] [VOTE] Add PHP Engine Constant Identifier

[Davey Shafik]

Hi all,

As noted last week, I'm now opening up the vote for adding a PHP Engine
Identifier constant to PHP 7.2+ (and more importantly, to the language
spec). Additionally, there is a second vote to add corresponding
PHP_ENGINE_(*_)VERSION(_ID) constants.

https://wiki.php.net/rfc/php_engine_constant

Thanks,

- Davey

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace withcomposer/pickle

[Davey Shafik]

On Thu, Sep 8, 2016 at 3:18 PM, Lester Caine  wrote:

> On 08/09/16 18:40, Larry Garfield wrote:
> > Note: Whether that is a good trend or bad trend I will not claim, and
> > that is largely irrelevant.  But that is where the river is running, and
> > trying to swim upstream against it is not going to be very effective.
>
> Trying to swim against the tide of M$ 'improvements' has been something
> I've been doing since 1992. Silly little things like when you remote
> access a local server which in addition to serving web pages is also
> displaying the information on monitors, and creating announcements via
> the PA system. Does the M$ remote desktop offering still switch off the
> local sound card 'to improve the remote performance'? I still use VNC
> simply to ensure the locals site is NOT brought down. And the local
> technicians  have to log in via their own accounts so unless care is
> taken, NONE of the shares or tools they need are available because of
> the move to secure activity between accounts. ALL of the work being cone
> by these machines is central, and every user needs to see the same set
> of tools, and file system. They do not need to live in their own little
> world secure from other technicians and they ALL need to see the same
> desktop.
>
> Of cause where sites are not being heavily audited for security we can
> stick up two fingers and the only active user is root - totally
> politically incorrect - but it prevents the bulk of the problems caused
> when some 'developer' screws up something global after a Linux update.


There is a fundamental difference of approach here. In the modern approach,
the ideal is easy replication of _exact_ environment somewhere else.
Whether that be your laptop and desktop machines, your machine, and your
team members, or your machine and a cloud providers ephemeral instance. Or,
in this case: between users on the _same_ machine.

The point of the composer.lock file is that a "composer install" command
will installs the _exact_ same versions everywhere. Even if it's coming
from VCS, it'll record and install the same commit everywhere. It even
records the shasum of the versioned package, so that if the server replaces
it then you'll know.

The primary issue in your case is that you're duplicating the files for
each user. There is nothing stopping you putting the code in a single place
and doing a composer install then making sure all the users can access it,
whether through symlinks, or just simple permissions (and possibly PATH
changes).

In your case, I think the reason you are centralizing is because you want
to ensure nobody touches the file — this is more about security and lack of
trust, than anything else. Typically, there is more security in this
approach, as nothing is owned or run as root.

Anyway, this is far off topic IMO. This RFC isn't going to kill PEAR (any
deader than it already is :P) it will simply unbundle it from core. If you
want to continue using it, then by all means do so. And ignore the
potential fact that composer/pickle may be bundled instead.

- Davey

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

On Thu, Sep 8, 2016 at 1:34 AM, Michael Morris  wrote:

> On Thu, Sep 8, 2016 at 4:27 AM, Daniel Morris 
> wrote:
>
> > On Thu, 8 Sep 2016, at 08:43 AM, Tony Marston wrote:
> > > Perhaps users could be prevented from making such basic mistakes if
> they
> > > had
> > > a 21st century web interface instead of the archaic command line.
> >
> > Why don't you make one?
> >
> >
> Because that might take real skill that Tony doesn't have?


Please refrain from personal attacks on this list.

- Davey

Re: [PHP-DEV] Re: [PREVOTE] PHP Engine Constants

[Davey Shafik]

On Tue, Sep 6, 2016 at 2:51 PM, Dan Ackroyd <dan...@basereality.com> wrote:

> On 6 September 2016 at 22:39, Davey Shafik <da...@php.net> wrote:
> >
> >
> > The key to this is that it's part of the spec. If you actually want to
> > follow the spec, you have to implement it this way. If you don't, then
> > you're a bad person. :P
>
>
> Perhaps you can make the RFC text be clearer then. e.g. to this bit:
>
> "PHP_ENGINE — A simple string denoting the runtime engine, e.g. php or
> hhvm"
>
> add something like "The contents of the string MUST be unique to the
> runtime engine being used."
>
> because currently, to me, there's nothing in the RFC that actually
> says how it needs to be implemented by other engines.


I'm not sure how to make this more clear:

> This RFC proposes to add a new constant that explicitly denotes the
engine being used, and more importantly makes it's use as such part of the
language spec.

I will try, but any suggestions are welcome

- Davey

Re: [PHP-DEV] Re: [PREVOTE] PHP Engine Constants

[Davey Shafik]

On Tue, Sep 6, 2016 at 1:32 PM, Dan Ackroyd <dan...@basereality.com> wrote:

> On 5 September 2016 at 19:43, Davey Shafik <da...@php.net> wrote:
> >
> > Instead, it would be better to check PHP_ENGINE ===
> > 'hhvm' && PHP_ENGINE_VERSION_ID <= 30813
>
> And then when the next people who want to build an alternative engine
> come along, they will include this constant, to make their engine as
> 'compatible' as possible with the current PHP engine.
>
> i.e. adding this doesn't provide a way of telling real PHP apart from
> something that is copying it.
>

The key to this is that it's part of the spec. If you actually want to
follow the spec, you have to implement it this way. If you don't, then
you're a bad person. :P


> > Then you need to check for HHVM_VERSION
>
> So...that sounds like the correct thing to be checking for. Test for
> known "almost but not quite PHP" engines, otherwise assume that you're
> running on real PHP.
>

The problem is also when running on unknown PHP engines. Assumptions are
terrible things.

- Davey

Re: [PHP-DEV] Missing reflection info about strict types?

[Davey Shafik]

On Mon, Sep 5, 2016 at 1:13 PM, Nicolas Grekas 
wrote:

> > Why do you concatenate these files in the first place?
> >
> >
>
> It's not specifically me but Symfony's ClassCollectionLoader::load()
> method, which generates a single file with common classes inlined for
> faster bootstrapping (the perf gain is objectively measurable).
>
> You give this method a list of classes that are always required, and it
> computes all the required parents/interfaces/traits they use, by using
> reflection of course. It turns namespace to the bracketed syntax, orderd
> things as required (parents first), and dumps everything in one php file.
>
> The issue came to our tracker that this process was broken once one wanted
> to inline a strict class there, either directly or indirectly through the
> parent chain.
>

Again, there is not such thing as a strict class. You should be stripping
ALL declare(strict_types=0/1) from the class files, and even if enabled it
at the top of final generated file it wouldn't make any difference _unless_
you're calling the classes IN the generated file. Anything you include it
into will decide for itself whether it is strict or not.


> I worked on the issue and fixed it by replacing the inlining by a "require"
> for now.
>
> Here is the pointer for the fix (then the class & the issue):
> https://github.com/symfony/symfony/pull/19859/files?w=1


I would highly recommend using sprintf() instead of str_replace() to inject
your regex. And again, strip the declare lines completely. Then you can
concat.

https://github.com/symfony/symfony/pull/19859/files?w=1#diff-e37b3a45b919f2dd526570353388e4a5R1

This isn't a class with strict types, it's a file that will enforce strict
types on code that _it_ calls, not code that calls the class defined inside
it.

- Davey

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

On Mon, Sep 5, 2016 at 8:31 AM, Michael Morris  wrote:

> Please be cautious - composer isn't a complete replacement for PEAR
> because it doesn't behave the same way. For the most part this is a good
> thing, but please consider the following.
>
> On not one but two occasions I was tasked after being hired with upgrading
> PHP versions from 4.x to 5.3.  In both cases the programmers on staff who
> had inherited the balls of mud in question swore up and down it couldn't be
> done - on both occasions it was because they weren't copying the PEAR
> libraries over to the new PHP install.
>
> PEAR is a global installer, and unfortunately I imagine there are a lot of
> legacy sites that have been inherited by inexperienced coders who don''t
> know what it is (cause it is used so rarely these days) that have pear libs
> in use. If they need to build a new version of PHP they are at a complete
> loss unless they know what they are doing because, more often than not, the
> requirement of pear libraries in PHP apps that use them go undocumented.
>

Even ten years ago, best practices was not to install PEAR packages
globally due to different projects on shared hosts needing different
versions. Instead we installed them locally, committed them to RCS, and
used the include_path to control include locations.


> Composer is superior for several reasons, but one of them is that it
> doesn't share this flaw. The requirements of a composer project are listed
> explicitly in the composer.json file - often down to the version # of the
> code in question.
>
> While abandoning PEAR seems sensible, abandoning its plugins, not so much.
>

Nobody is suggesting this. Though it might be good to push them off from
under php.net, that doesn't stop them existing, and that's not part of this
RFC.


> To say nothing of PECL extensions which are, if I recall correctly,
> written in C++ and extend the PHP runtime directly.
>

Written in C, and yes, that's the difference between PEAR and PECL, the
former are userland, the latter are written in C. This is where pickle
comes in.


> Also, as Tony Marston pointed out, there are CPanel systems that allow the
> pear libraries to be managed from a web gui.  Given time I'm sure the folks
> at cpanel will build new interfaces for new systems if it's possible.
> Composer however doesn't really allow for this since the dependencies
> belong to the PHP application, not the server. Does it make sense for any
> new system to allow for server wide installing?  Composer does have global
> requiring, but it's usually for support tools meant for use at the command
> line like PHP Unit.
>

Actually, I think Tony is pointing to pear-web, a PEAR provided web
interface for PEAR itself (which can be used instead of the CLI tool).
Which isn't going away, it will just be unbundled. In 8.0.

Nothing we're doing changes anything for CPanel and the like except they
may now need to replicate the install part of PEAR themselves from the PHP
compilation.  It's very simple.


> Despite the misgivings above, I do support the aims of this RFC and hope
> they are considered going forward.
>

Thank you.

- Davey

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

On Mon, Sep 5, 2016 at 8:57 AM, Lester Caine  wrote:

> On 05/09/16 16:31, Michael Morris wrote:
> > Also, as Tony Marston pointed out, there are CPanel systems that allow
> the
> > pear libraries to be managed from a web gui.  Given time I'm sure the
> folks
> > at cpanel will build new interfaces for new systems if it's possible.
> > Composer however doesn't really allow for this since the dependencies
> > belong to the PHP application, not the server.
>
> This is the part of the tree that I'm also climbing where we are helping
> port legacy hosting over to to a newer framework. Silly little things
> like mysql being dropped while there is nobody to re-write all the code
> to mysqli.


https://github.com/dshafik/php7-mysql-shim — I already solved that problem,
at least in the short term.


> Restoring extensions from pecl still needs pecl to exist even
> for pickle to access them including the web interface to catalogue them?
> And I view PEAR in the same light. So this is not about 'Deprecate' the
> code, but just the loader bit?


Nobody is saying to do anything except unbundle the command line tools.
Also, pickle can install pecl extensions from places like publicly
accessible git and svn repos (like github, git.php.net or svn.php.net).

Re: [PHP-DEV] Re: [PREVOTE] PHP Engine Constants

[Davey Shafik]

On Mon, Sep 5, 2016 at 11:19 AM, Andrea Faulds <a...@ajf.me> wrote:

> Hi Davey,
>
> Davey Shafik wrote:
>
>> A while back I brought a small RFC to internals, that proposed a set of
>> constants that were specifically for alternative implementations to
>> identify themselves as such if they want to conform to the spec.
>>
>> https://wiki.php.net/rfc/php_engine_constant
>>
>> There were some folks who didn't like it, but nobody suggested different
>> implementations, just didn't feel it was necessary. As such, I'm planning
>> to
>> bring it to a vote next week - this is simply a heads up as it's been a
>> while
>> and I want to give a chance for any objections other than not wanting it
>> to
>> be voiced before I open it up for voting.
>>
>
> This is an interesting idea. Have you asked the HHVM team what they think
> about it? Their input is probably more important than ours, as the foremost
> alternative implementation.
>
> The implications of it are interesting. Currently, PHP doesn't really have
> any separation between the current version of the PHP interpreter and the
> version of the language. Despite the specification efforts, PHP versions
> are effectively defined by the main implementation.
>
> Would this RFC be changing that, decoupling the version of PHP, the
> language, from PHP, the interpreter? Would we no longer report the version
> of PHP as, say, “7.1.1”, but instead as just “7.1”, and put “7.1.1” as the
> engine version? The micro version, at least with the modern release
> process, is only meaningful for the PHP interpreter, and not other
> implementations.
>

As per the RFC, the PHP_*_VERSION (and related constants) and the
PHP_ENGINE_*_VERSION constants would be the same for php.net.


> Also, isn't there a danger of code sniffing for the engine? I wouldn't be
> entirely surprised if, in future, HHVM might start pretending to be PHP by
> default.
>

This is actually the problem right now, they already _do_ this, despite not
being 100% to spec. Then you need to check for HHVM_VERSION and work around
those differences. Instead, it would be better to check PHP_ENGINE ===
'hhvm' && PHP_ENGINE_VERSION_ID <= 30813


> Anyway, that's just a few thoughts of mine.


Thanks!

- Davey

Re: [PHP-DEV] Missing reflection info about strict types?

[Davey Shafik]

> On Sep 5, 2016, at 02:38, Nicolas Grekas  wrote:
> 
> Hello,
> 
> It looks like we miss a way to check by reflection if a function/method has
> strict types enabled or not.
> 
> We'd need to do this in Symfony to generate a file with concatenated
> classes, but split "declare_strict=1" classes out so that they don't break
> (because there is no way to create a single file that contains both strict
> and non-strict classes unfortunately also).
> 
> Would it be possible to expose some flavor of ZEND_ACC_STRICT_TYPES to
> userland?

Strict types are only enforced from the CALL site. A library author cannot 
dictate that their code be called using strict types or not, only the file 
actually calling the library methods can. Though, regardless, the type hints do 
ensure that the value received is of the type specified, you just won't know if 
it was coerced or not.

Just like when you import a namespaced class and alias it, the alias only works 
in the file the "use " statement is in.

Therefore, you cannot actually author strict or non-strict classes period, 
unless they are only called in the file in which they are defined.

This means you cannot reflect on it, unless we start doing reflection on source 
code files themselves.

 - Davey

Re: [PHP-DEV] Non-conflicting PHP 5 and 7 builds

[Davey Shafik]

Jordan,

This was a choice they made, yet the author of the Debian/Ubuntu packages
has side-by-side installable versions from 5.5-7.1 in his own PPA:

https://launchpad.net/~ondrej/+archive/ubuntu/php

It's not only currently feasible, it has been done, the _project_ chose not
to do it.

- Davey

On Sun, Sep 4, 2016 at 12:57 AM, Jordan Gigov  wrote:

> I can see your argument for using prefix, but that would not provide a
> solution to package maintainers who may want to give their users a choice.
> I was recently surprised when upgrading from Ubuntu 14 to 16 that it
> replaced PHP 5 with 7 entirely. They were forced into choosing between the
> two at a time when most developers will have to maintain both versions for
> several more years for different projects.
>
>
> And what do you mean --program-suffix is broken? What do you get and expect
> to get? With or without my changes it seems work as intended.
>
> 2016-09-02 18:28 GMT+03:00 Levi Morrison :
>
> > The issue is that you are writing to the same prefix. Just write them
> > to different prefixes and reference them separately. This is not a
> > unique-to-php situation. At work we maintain many different
> > simultaneous versions of Python, for example.
> >
> > With that said it looks like the program suffixes are broken. If
> > --program-suffix=7 is set then I'd expect php7, phpize7 (or php7ize,
> > don't really care), etc.
> >
>

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

On Sat, Sep 3, 2016 at 2:53 PM, Rowan Collins 
wrote:

> On 03/09/2016 19:44, Lester Caine wrote:
>
>> So this RFC is simply proposing that PHP-FIG becomes the standard for
>> writing PHP code?
>>
>
> No, that is not at all what this RFC is proposing. The RFC is simply
> proposing to stop bundling the command-line tool "pear" with default PHP
> builds.
>
> The PEAR coding standards will still exist, the packages created according
> to them will still be usable, and you'll still be able to download pear, or
> pyrus, to access them. You could also use composer to access most of them,
> and publish packages adhering to that style on packagist.org, or pretty
> much any platform you want.
>
> The only reason I mentioned PHP-FIG is because they are trying to write a
> modern standard for writing interoperable PHP libraries, which is what you
> asked for.
>
> I guess we could have a philosophical debate about what it means for
> something to be "the standard" rather than "a standard", and whether PEAR
> was "more official" than PHP-FIG, and just who gets to decide what PHP is.
>
> But once again, I find myself being drawn into an off-topic debate about
> coding styles, and I would like to apologise to Davey as it has nothing to
> do with his RFC.


No need to apologize, thank you for defending my idea and so eloquently — I
will amend the RFC with your earlier suggestions; being as I will do so
almost verbatim, would you mind being added as a co-author? I think it's a
substantial contribution :)

- Davey

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

On Fri, Sep 2, 2016 at 12:57 PM, James Gilliland <neclim...@gmail.com>
wrote:

> On Fri, Sep 2, 2016 at 2:33 PM Davey Shafik <m...@daveyshafik.com> wrote:
>
> > Hi internals,
> >
> > I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and
> remove
> > in 8.0), as well as add composer/pickle (optional in 7.2, default in
> 7.3+)
> > in their place.
> >
> > https://wiki.php.net/rfc/deprecate-pear-include-composer
> >
> > I highly recommend reading the twitter poll and accompanying thread at
> > https://twitter.com/dshafik/status/756337267547832320
> >
> > I believe that pickle solves the issues with regards to pecl, and have
> run
> > the idea passed Jordi and Pierre. Both are fine with this RFC. :)
> >
> > I understand that adding in composer/pickle is just setting us up for
> > having a future "Deprecate composer/pickle & Replace with foo/bar" RFC,
> so
> > I've proposed the voting reflect that some people will just want to
> > deprecate/remove pear/pecl and not replace them at all.
> >
> > I'm also proposing voting choices around the optional/default
> introduction
> > of composer/pickle.
> >
> > - Davey
> >
> Will composer/pickle address the unsolved PHP compatibility issue that
> makes pecl a pain following the PHP 7 release?
>

Which, exactly?

- Davey

[PHP-DEV] Re: [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

Also, just wanted to say:

As a former fairly major contributor to PEAR (see:
http://pear.php.net/user/davey) I understand that PEAR has a special place
in the heart of many old-school PHP developers — but I believe that the
community has spoken, through lack of action on PEARs part, and the rapid
adoption of composer on the general communities part.

We should probably also have some conversations about actually sunsetting
the PEAR and PECL sites and deprovisioning those resources. But that's a
whole other conversation ;)

- Davey

On Fri, Sep 2, 2016 at 12:32 PM, Davey Shafik <m...@daveyshafik.com> wrote:

> Hi internals,
>
> I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
> in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
> in their place.
>
> https://wiki.php.net/rfc/deprecate-pear-include-composer
>
> I highly recommend reading the twitter poll and accompanying thread at
> https://twitter.com/dshafik/status/756337267547832320
>
> I believe that pickle solves the issues with regards to pecl, and have run
> the idea passed Jordi and Pierre. Both are fine with this RFC. :)
>
> I understand that adding in composer/pickle is just setting us up for
> having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
> I've proposed the voting reflect that some people will just want to
> deprecate/remove pear/pecl and not replace them at all.
>
> I'm also proposing voting choices around the optional/default introduction
> of composer/pickle.
>
> - Davey
>

[PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Davey Shafik]

Hi internals,

I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and remove
in 8.0), as well as add composer/pickle (optional in 7.2, default in 7.3+)
in their place.

https://wiki.php.net/rfc/deprecate-pear-include-composer

I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320

I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)

I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.

I'm also proposing voting choices around the optional/default introduction
of composer/pickle.

- Davey

Re: [PHP-DEV] SQLite 3.14

[Davey Shafik]

Good find with that other test!

I don't see any reason not to fix it for 5.6+

- Davey

On Fri, Sep 2, 2016 at 12:08 PM, Christoph M. Becker <cmbecke...@gmx.de>
wrote:

> On 31.08.2016 at 05:46, Davey Shafik wrote:
>
> > Sorry, I dropped the ball on this one:
> >
> > ../sapi/cli/php   -d "output_handler=" -d "open_basedir=." -d
> > "disable_functions=" -d "output_buffering=Off" -d "error_reporting=32767"
> > -d "display_errors=1" -d "display_startup_errors=1" -d "log_errors=0" -d
> > "html_errors=0" -d "track_errors=1" -d "report_memleaks=1" -d
> > "report_zend_debug=0" -d "docref_root=" -d "docref_ext=.html" -d
> > "error_prepend_string=" -d "error_append_string=" -d "auto_prepend_file="
> > -d "auto_append_file=" -d "ignore_repeated_errors=0" -d "precision=14" -d
> > "memory_limit=128M" -d "log_errors_max_len=0" -d
> "opcache.fast_shutdown=0"
> > -d "opcache.file_update_protection=0" -f
> > "/php-src/ext/sqlite3/tests/sqlite3_21_security.php"
> >
> > I think the issue is that the test isn't run in ext/sqlite3/tests, but
> from
> > the root of the checkout, which means that open_basedir=.  would include
> > everything in the repo, including the attempt "../bad" directory.
>
> Ah, I have not thought of running in a root directory directly (or would
> have expected that "../bad" would still trigger the open_basedir warning).
>
> > Potential solutions:
> >
> > Change the path to be "../../../../../bad" to ensure it's outside the
> > top-level of the script.
>
> If "../bad" doesn't trigger the open_basedir restriction, "../../bad"
> most likely also wouldn't.  Please correct me if I'm wrong.
>
> > Add a: chdir(__DIR__); at the top.
>
> Indeed, using chdir() seems to be the proper way to test for
> open_basedir restrictions, see
> <https://github.com/php/php-src/blob/PHP-7.0.11/tests/
> security/open_basedir.inc#L12-L14>.
>
> Should that be changed for PHP-5.6+?
>
> Cheers!
>
> > Thoughts?
> >
> > On Fri, Aug 19, 2016 at 5:31 PM, Anatol Belski <anatol@belski.net>
> > wrote:
> >
> >> Hi Davey,
> >>
> >>> -Original Message-
> >>> From: Davey Shafik [mailto:da...@php.net]
> >>> Sent: Friday, August 19, 2016 7:09 PM
> >>> To: Christoph M. Becker <cmbecke...@gmx.de>
> >>> Cc: Anatol Belski <anatol@belski.net>; internals@lists.php.net
> >>> Subject: Re: [PHP-DEV] SQLite 3.14
> >>>
> >>> Christophe,
> >>>
> >>> I got the failure multiple times in my Debian Jessie docker container
> >> that I use
> >>> for builds - you can check it out yourself at
> >> https://github.com/dshafik/php-build
> >>> to see the setup.
> >>>
> >>> Thanks for looking into this!
> >>>
> >>> - Davey
> >>>
> >>> On Sat, Aug 20, 2016 at 01:35 Christoph M. Becker <cmbecke...@gmx.de
> >>> <mailto:cmbecke...@gmx.de> > wrote:
> >>>
> >>>
> >>>   Hi Davey!
> >>>
> >>>   On 19.08.2016 at 15:32, Davey Shafik wrote:
> >>>
> >>>   > I saw this failure while packaging 7.1.0beta3, and assume it
> >> might be
> >>>   > related to your update:
> >>>   >
> >>>   > FAIL SQLite3 open_basedir checks
> >>>   > [ext/sqlite3/tests/sqlite3_21_security.phpt]
> >>>   >
> >>>   > DIFF
> >>>   > 006-
> >>>   > 007- Warning: SQLite3::__construct(): open_basedir restriction
> in
> >>> effect.
> >>>   > File(%s) is not within the allowed path(s): (.) in
> >>>   > %ssqlite3_21_security.php on line %d
> >>>   > 008- Exception: open_basedir prohibits opening %s in
> >>>   > %ssqlite3_21_security.php:%d
> >>>   > 009- Stack trace:
> >>>   > 010- #0 %ssqlite3_21_security.php(%d):
> SQLite3->__construct('%s')
> >>>   > 011- #1 {main}
> >>>   > DONE
> >>>   >
> >>>   > Can you please look into this in time for RC1?
> >>>
> >>>   

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

[Davey Shafik]

That would be why I thought it hadn't been missed!

Thanks Scott (and Christoph :)

- Davey

On Fri, Sep 2, 2016 at 8:19 AM, Scott Arciszewski <sc...@paragonie.com>
wrote:

> https://github.com/php/php-src/pull/1996
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>
>
> On Fri, Sep 2, 2016 at 11:18 AM, Scott Arciszewski <sc...@paragonie.com>
> wrote:
>
>> I thought someone beat me to it?
>>
>> Scott Arciszewski
>> Chief Development Officer
>> Paragon Initiative Enterprises <https://paragonie.com>
>>
>> On Fri, Sep 2, 2016 at 11:18 AM, Davey Shafik <da...@php.net> wrote:
>>
>>> I would still be OK adding this in RC2, TBH. I didn't realize it was
>>> missed, and it's something we _need_ to do.
>>>
>>> - Davey
>>>
>>> On Fri, Sep 2, 2016 at 8:08 AM, Leigh <lei...@gmail.com> wrote:
>>>
>>>> On 22 March 2016 at 17:00, Scott Arciszewski <sc...@paragonie.com>
>>>> wrote:
>>>> > Hi all,
>>>> >
>>>> > https://wiki.php.net/rfc/mcrypt-viking-funeral
>>>> >
>>>> > The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a
>>>> 79.3%
>>>> > favorable response, which exceeds the 2/3 majority by a significant
>>>> margin.
>>>> >
>>>> > Thanks to everyone who voted or participated in this discussion.
>>>> >
>>>> > I've heard and respect some of the objections raised by folks who
>>>> voted No,
>>>> > but moving this liability out of the core into PECL as soon as
>>>> possible is
>>>> > not only a good move for the security of PHP applications, but now we
>>>> know
>>>> > it's the choice the community wants.
>>>> >
>>>> > As promised, I'll get the E_DEPRECATED patch written soon.
>>>>
>>>> As we're now at RC1, I assume it is too late to push forward with this?
>>>>
>>>
>>>
>>
>

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

[Davey Shafik]

I would still be OK adding this in RC2, TBH. I didn't realize it was
missed, and it's something we _need_ to do.

- Davey

On Fri, Sep 2, 2016 at 8:08 AM, Leigh  wrote:

> On 22 March 2016 at 17:00, Scott Arciszewski  wrote:
> > Hi all,
> >
> > https://wiki.php.net/rfc/mcrypt-viking-funeral
> >
> > The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a
> 79.3%
> > favorable response, which exceeds the 2/3 majority by a significant
> margin.
> >
> > Thanks to everyone who voted or participated in this discussion.
> >
> > I've heard and respect some of the objections raised by folks who voted
> No,
> > but moving this liability out of the core into PECL as soon as possible
> is
> > not only a good move for the security of PHP applications, but now we
> know
> > it's the choice the community wants.
> >
> > As promised, I'll get the E_DEPRECATED patch written soon.
>
> As we're now at RC1, I assume it is too late to push forward with this?
>

Re: [PHP-DEV] [PREVOTE] PHP Engine Constants

[Davey Shafik]

On Thu, Sep 1, 2016 at 12:04 PM, Fleshgrinder <p...@fleshgrinder.com> wrote:

> On 9/1/2016 8:02 PM, Davey Shafik wrote:
> > Hey all,
> >
> > A while back I brought a small RFC to internals, that proposed a set of
> > constants that were specifically for alternative implementations to
> > identify themselves as such if they want to conform to the spec.
> >
> > https://wiki.php.net/rfc/php_engine_constant
> >
> > There were some folks who didn't like it, but nobody suggested different
> > implementations, just didn't feel it was necessary. As such, I'm
> planning to
> > bring it to a vote next week - this is simply a heads up as it's been a
> > while
> > and I want to give a chance for any objections other than not wanting it
> to
> > be voiced before I open it up for voting.
> >
> > The vote will be a straight 50%+1 yes/no vote.
> >
> > - Davey
> >
>
> +1 from my side.
>
> What do you think about including a platform and architecture identifier
> too?
>
> const string PHP_ENGINE_PLATFORM = '';
>
> WINDOWS
> LINUX
> MACOS
> CYGWIN
> FREEBSD
> SOLARIS
> ...
>
> This would solve all the tricks we see in various code bases that try to
> determine what platform the current PHP installation is running on,
> e.g.: if (DIRECTORY_SEPARATOR === '\\') could be replaced with a more
> readable if (PHP_ENGINE_PLATFORM === 'WINDOWS').
>
> const string PHP_ENGINE_ARCHITECTURE = '';
>
> x86
> x64
> ia64
> arm
> ...
>
> This is not required as often but still needed at some places. This
> would allow to replace checks like if (PHP_INT_SIZE === 8) with if
> (PHP_ENGINE_ARCHITECTURE === 'x64').


We already have PHP_OS, and architecture is likely too broad to determine
specific things like INT size etc. That is, while you may be using things
like INT size to determine architecture, the inverse is not necessarily
true.

I don't think these really fit in with the goal of this RFC, which is more
about identifying the spec being implemented in alternative runtimes; while
your suggestions would just be part of the spec and would just be in those
runtimes like any other feature.

- Davey

[PHP-DEV] [PREVOTE] PHP Engine Constants

[Davey Shafik]

Hey all,

A while back I brought a small RFC to internals, that proposed a set of
constants that were specifically for alternative implementations to
identify themselves as such if they want to conform to the spec.

https://wiki.php.net/rfc/php_engine_constant

There were some folks who didn't like it, but nobody suggested different
implementations, just didn't feel it was necessary. As such, I'm planning to
bring it to a vote next week - this is simply a heads up as it's been a
while
and I want to give a chance for any objections other than not wanting it to
be voiced before I open it up for voting.

The vote will be a straight 50%+1 yes/no vote.

- Davey

[PHP-DEV] PHP 7.1.0RC1 is available for testing

[Davey Shafik]

Hi,

The first release candidate for PHP 7.1.0, RC1 was just released and can be
downloaded from:

https://downloads.php.net/~davey/

The Windows binaries are available at

http://windows.php.net/qa/

For the list of bug fixes and other changes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-7.1.0RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The next RC release, RC2, is planned for September 15th.


Below is the verification information for the downloads:

php-7.1.0RC1.tar.bz2
SHA256 hash:
0ab8830dadcad235e4252feda8b33c43db1ba623926db6007aa1c392bb8ee524
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXxw1SAAoJEGWqzKLMO04mZtUIAKeyGdjkaP4khzz6kdZceOVT
lxWzy/7p39nXGrP2zaVIYkt5dIniwlBEbauUlxSDW/elqSQYA5LTWvgr3EKt3mHp
IY2FfYxRl4ZbkeanColEoKCrKW+eW83iB0mcdIkZw+fJgLwPzVoUXa8BKubXSaBH
0z3R1OtxzTGWAXEU8nJB1MhimcBPtB6ZrkBlfA509QgUF9L8UhYIk/+yE4yO3l73
CliPlon9Yr+U32p7A6QT9dZIlhY1wUf3yaoprh2OET7xDv172ju7eryZzi+cRI0R
hlRZnJk5pvamINJpX/M5/BAbFFDpL/dGAeE91LJR9oOs2xgbmVR2WKbV2eoiTFI=
=Sqla
-END PGP SIGNATURE-


php-7.1.0RC1.tar.gz
SHA256 hash:
b1b89fd16af37869cf3f58812b9d54362b09ab8de5e34ec87d39c57620238ae6
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXxw1jAAoJEGWqzKLMO04mj4IIAJlJNYAqXqLQuaCXTT7XDn4O
AmhbeJFjW+UXVq92VeVlIg50c7FgwwXC3/b5U7p3maLu36pdPqTwKLdNftwSkl2s
ucM8tJ65snDOQPn+SjE5tQqoQNjZiNuGlQDXa//x8mPrOyTWTW+EWGYJHx+NTBSv
ndsP+nzIDMbQfvY4X3dB1Oity5msst6Y1KpUv5fYKES2fWBQ85MYDja65o8GXVnV
nvd6OA1teQ7FdOw1QEC+aMW4p2B3TD5uK6/5/wmIcZtU4PJFmIcIn7+ag26WDpTp
DXsM39ABrtU7ZO2BHX4DbF2nhuoikc2B0Y9M6NaCHDRNSK+f6MUtxImX7xFylTg=
=+GdV
-END PGP SIGNATURE-


php-7.1.0RC1.tar.xz
SHA256 hash:
0ac0e493635ae4cb48d3449d654af07ba2a8d7cdb1e48dd07b227937cf0cdf2b
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXxw1kAAoJEGWqzKLMO04mwckH/1Pwfd1DLmkNmCgQC+GvlxkS
L8STqR4p8n3WbDE8eBGe0bEzFdYcXiEUjfp8KCzXWoFVfWOduUgll32g3ElwssKs
mwYChlMSRRYaJUmdTo/rK9LJROJhiFHwM5ObUdDSIbh30bF2vBUc7Bgwu0RP/qgD
uvFARpSGYOkHhf52BfWkAQC9kU4/5WRSNdZu64+Y91mL9//RekkPDhxIF2NKPkDg
fYPPLOCqJ5Vdm5tdiXLBQ08DNiw29VYv68BQe/68MfYkLLbKu1Mg8FNl0bqmvnbj
/Vg3CWQ3eY4sLpIQiuU3XIfA9Bm3XQBt0MVmncP8FlDpzMxYPPELJc/mM803jsI=
=qTP9
-END PGP SIGNATURE-

Re: [PHP-DEV] SQLite 3.14

[Davey Shafik]

Sorry, I dropped the ball on this one:

./sapi/cli/php   -d "output_handler=" -d "open_basedir=." -d
"disable_functions=" -d "output_buffering=Off" -d "error_reporting=32767"
-d "display_errors=1" -d "display_startup_errors=1" -d "log_errors=0" -d
"html_errors=0" -d "track_errors=1" -d "report_memleaks=1" -d
"report_zend_debug=0" -d "docref_root=" -d "docref_ext=.html" -d
"error_prepend_string=" -d "error_append_string=" -d "auto_prepend_file="
-d "auto_append_file=" -d "ignore_repeated_errors=0" -d "precision=14" -d
"memory_limit=128M" -d "log_errors_max_len=0" -d "opcache.fast_shutdown=0"
-d "opcache.file_update_protection=0" -f
"/php-src/ext/sqlite3/tests/sqlite3_21_security.php"

I think the issue is that the test isn't run in ext/sqlite3/tests, but from
the root of the checkout, which means that open_basedir=.  would include
everything in the repo, including the attempt "../bad" directory.

Potential solutions:

Change the path to be "../../../../../bad" to ensure it's outside the
top-level of the script. Add a: chdir(__DIR__); at the top.

Thoughts?

On Fri, Aug 19, 2016 at 5:31 PM, Anatol Belski <anatol@belski.net>
wrote:

> Hi Davey,
>
> > -Original Message-
> > From: Davey Shafik [mailto:da...@php.net]
> > Sent: Friday, August 19, 2016 7:09 PM
> > To: Christoph M. Becker <cmbecke...@gmx.de>
> > Cc: Anatol Belski <anatol@belski.net>; internals@lists.php.net
> > Subject: Re: [PHP-DEV] SQLite 3.14
> >
> > Christophe,
> >
> > I got the failure multiple times in my Debian Jessie docker container
> that I use
> > for builds - you can check it out yourself at
> https://github.com/dshafik/php-build
> > to see the setup.
> >
> > Thanks for looking into this!
> >
> > - Davey
> >
> > On Sat, Aug 20, 2016 at 01:35 Christoph M. Becker <cmbecke...@gmx.de
> > <mailto:cmbecke...@gmx.de> > wrote:
> >
> >
> >   Hi Davey!
> >
> >   On 19.08.2016 at 15:32, Davey Shafik wrote:
> >
> >   > I saw this failure while packaging 7.1.0beta3, and assume it
> might be
> >   > related to your update:
> >   >
> >   > FAIL SQLite3 open_basedir checks
> >   > [ext/sqlite3/tests/sqlite3_21_security.phpt]
> >   >
> >   > DIFF
> >   > 006-
> >   > 007- Warning: SQLite3::__construct(): open_basedir restriction in
> > effect.
> >   > File(%s) is not within the allowed path(s): (.) in
> >   > %ssqlite3_21_security.php on line %d
> >   > 008- Exception: open_basedir prohibits opening %s in
> >   > %ssqlite3_21_security.php:%d
> >   > 009- Stack trace:
> >   > 010- #0 %ssqlite3_21_security.php(%d): SQLite3->__construct('%s')
> >   > 011- #1 {main}
> >   > DONE
> >   >
> >   > Can you please look into this in time for RC1?
> >
> >   I've just checked again with the tagged PHP-7.1.0beta3, but the
> test
> >   succeeds on my machine.  Therefore it's hard for me to assess what
> is
> >   wrong.  According to the diff, it appears that the second DB which
> >   shouldn't be created according to the open_basedir restriction, is
> >   actually successfully created.
> >
> >   Anyway, it's rather unlikely that an open_basedir related failure
> is
> >   caused by updating SQLite, as this check is part of the PHP
> binding[1],
> >   which has not been affected by this commit.  The issue might be
> caused
> >   by commit cc125f27[2], but that's also somewhat unlikely, because
> the
> >   Travis checks usually succeed generally.
> >
> >   Can you reproduce the test failure?  In which enviroment?
> >
> >   [1] <https://github.com/php/php-src/blob/PHP-7.1.0beta3/ext/
> sqlite3
> >   /sqlite3.c#L125 <https://github.com/php/php-src/blob/PHP-
> > 7.1.0beta3/ext/sqlite3/sqlite3.c#L125> >
> >   [2] <https://github.com/php/php-src/commit/cc125f27>
> >
> I was checking this and saw no failure as well. From the test diff, it
> doesn't look like a crash but something with that try/catch block. Maybe
> there'll be more luck with a reproducer, if you could post the exact
> command line? You can read it from the corresponding .sh file or just by
> appending --verbose.
>
> Regards
>
> Anatol
>

Re: [PHP-DEV] Reverting "Too Few Arguments Exception" RFC

[Davey Shafik]

FTR, I've created a second PR, without the changes to the array functions:

https://github.com/php/php-src/pull/2100

This way we can go either way.

- Davey

On Sat, Aug 27, 2016 at 1:57 AM, Christoph M. Becker 
wrote:

> On 26.08.2016 at 16:48, Levi Morrison wrote:
>
> > On Fri, Aug 26, 2016 at 4:53 AM, Christoph M. Becker 
> wrote:
> >
> >> Finally, I wonder why array_diff(), for instance, even has an explicit
> >> check for ZEND_NUM_ARGS() and for Z_TYPE() != IS_ARRAY instead of
> >> properly invoking zend_parse_parameters() with "aa+" instead of "+" in
> >> the first place?  Maybe I'm missing something, but otherwise I would
> >> suggest to fix that altogether instead of piecemeal, even if that has to
> >> wait until 8.0.
> >
> > Well, its behavior does differ with a single array: it will preserve
> > keys in this case. If more than one array is passed it will
> > numerically index the keys starting at zero. This is the only reason I
> > can think of.
>
> Indeed, I've overlooked that array_diff() accepts a single array.  So,
> ZPP could use "aa*".  My point is that it's better to rely on common
> checks (and respective errors), than to have individual checks for each
> (group of) function(s).  If that had already been the case, we wouldn't
> need to have this discussion. :-)
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] Reverting "Too Few Arguments Exception" RFC

[Davey Shafik]

On Thu, Aug 25, 2016 at 8:12 PM, Christoph M. Becker <cmbecke...@gmx.de>
wrote:

> On 24.08.2016 at 18:45, Nikita Popov wrote:
>
> > On Aug 24, 2016 9:55 AM, "Davey Shafik" <da...@php.net> wrote:
> >>
> >> Given this thread: http://externals.io/thread/233
> >>
> >> I'm not happy with the state of this going into RC1 next week, and
> without
> >> changes (such as the patch I provided), I would like to revert this
> change
> >> and leave it for 7.2.
> >>
> >> My patch will _retain_ BC for internal functions with non strict_types
> >> (except for the error message, which can be reconciled), and for
> functions
> >> that previously threw a TypeError, ArgumentCountError is a subclass so
> BC
> >> is preserved there also.
> >>
> >> The issue is that the array functions that do this argument count
> checking
> >> themselves and still issue a warning, regardless of strict_types.
> >>
> >> We can leave the original behavior for array functions, but they then
> >> differ from other internals functions.
> >>
> >> It is a BC break for userland functions (as per the RFC), throwing an
> >> ArgumentCountError regardless of strict_types.
> >>
> >> At this point, we _must_ come to consensus by Monday to get it into RC1
> > (if
> >> there are changes needed) or we should remove it from 7.1. Also, I would
> >> like someone more experienced to review my patch.
> >
> > I have some trouble understanding what the issue is here. The mentioned
> RFC
> > affects only userland functions, so the non-standard behavior of some
> array
> > functions shouldn't matter.
> >
> > Personally I am entirely indifferent as to what exception gets thrown
> when
> > too little arguments are passed -- this is a type of error that should
> not
> > be caught by anything but catch-all handlers.
> >
> > Inability to provide a more specific exception should not be a blocker
> for
> > this, especially as this is beyond the scope of the original RFC.
>
> Indeed, the RFC explicitly claims:
>
> | Behavior of internal functions is not going to be changed.
>

This is correct for functions that had the correct behavior before
(everything but array functions).

I can remove that part of the change — but if we're going to change it,
doing in 7.1 rather than > 7.1 would be best.

- Davey

Re: [PHP-DEV] Reverting "Too Few Arguments Exception" RFC

[Davey Shafik]

Nikita,

It is _always_ better to have more specific exceptions when it makes sense.
In this case, we need to do it to maintain BC.

One use-case that wasn't covered in the RFC, is the use of argument
unpacking with too few elements in the array/traversable — whereby you
would want to guard specifically for this condition, and handle it in a
non-generic way.

WRT to the internal functions, you were the person to bring up the behavior
of internal functions:

> Problem: We already use TypeError for this for internal functions. If we
want to introduce an extra exception for this, lets use it for internal
functions as well. In that case we should probably go with something that
applies not just to too few arguments, but also to too many.

During which I noticed the discrepancy with the array functions.

- Davey

On Thu, Aug 25, 2016 at 12:45 AM, Nikita Popov <nikita@gmail.com> wrote:

> On Aug 24, 2016 9:55 AM, "Davey Shafik" <da...@php.net> wrote:
> >
> > Hi all,
> >
> > Given this thread: http://externals.io/thread/233
> >
> > I'm not happy with the state of this going into RC1 next week, and
> without
> > changes (such as the patch I provided), I would like to revert this
> change
> > and leave it for 7.2.
> >
> > My patch will _retain_ BC for internal functions with non strict_types
> > (except for the error message, which can be reconciled), and for
> functions
> > that previously threw a TypeError, ArgumentCountError is a subclass so BC
> > is preserved there also.
> >
> > The issue is that the array functions that do this argument count
> checking
> > themselves and still issue a warning, regardless of strict_types.
> >
> > We can leave the original behavior for array functions, but they then
> > differ from other internals functions.
> >
> > It is a BC break for userland functions (as per the RFC), throwing an
> > ArgumentCountError regardless of strict_types.
> >
> > At this point, we _must_ come to consensus by Monday to get it into RC1
> (if
> > there are changes needed) or we should remove it from 7.1. Also, I would
> > like someone more experienced to review my patch.
> >
> > - Davey
>
> I have some trouble understanding what the issue is here. The mentioned
> RFC affects only userland functions, so the non-standard behavior of some
> array functions shouldn't matter.
>
> Personally I am entirely indifferent as to what exception gets thrown when
> too little arguments are passed -- this is a type of error that should not
> be caught by anything but catch-all handlers.
>
> Inability to provide a more specific exception should not be a blocker for
> this, especially as this is beyond the scope of the original RFC.
>
> Nikita
>

[PHP-DEV] Reverting "Too Few Arguments Exception" RFC

[Davey Shafik]

Hi all,

Given this thread: http://externals.io/thread/233

I'm not happy with the state of this going into RC1 next week, and without
changes (such as the patch I provided), I would like to revert this change
and leave it for 7.2.

My patch will _retain_ BC for internal functions with non strict_types
(except for the error message, which can be reconciled), and for functions
that previously threw a TypeError, ArgumentCountError is a subclass so BC
is preserved there also.

The issue is that the array functions that do this argument count checking
themselves and still issue a warning, regardless of strict_types.

We can leave the original behavior for array functions, but they then
differ from other internals functions.

It is a BC break for userland functions (as per the RFC), throwing an
ArgumentCountError regardless of strict_types.

At this point, we _must_ come to consensus by Monday to get it into RC1 (if
there are changes needed) or we should remove it from 7.1. Also, I would
like someone more experienced to review my patch.

- Davey

Re: [PHP-DEV] Incorrect Argument Count Error

[Davey Shafik]

On Mon, Aug 22, 2016 at 5:59 PM, Derick Rethans <der...@php.net> wrote:

> On Fri, 19 Aug 2016, Davey Shafik wrote:
>
> > b) a huge BC break (stuff that currently throws a warning in
> > strict_types mode will now throw an exception, similar BC break as
> > we're implementing for userland functions regardless of strict_types)
>
> IMO, that's not acceptable at all between 7.0 and 7.1
>

So… option C?

Bear in mind, this _only_ affects people who have turned on strict_types,
and makes it consistent across the language. If we had implemented type
hints internally it would also have errored out in 7.0, but would be a
TypeError (which ArgumentCountError extends and therefore it's BC).

(FYI, we both voted against this RFC, and I'm not happy about it but trying
to at least make it not as bad :P)

- Davey

Re: [PHP-DEV] Incorrect Argument Count Error

[Davey Shafik]

On Fri, Aug 19, 2016 at 10:27 PM, Kalle Sommer Nielsen <ka...@php.net>
wrote:

> 2016-08-19 15:05 GMT+02:00 Davey Shafik <da...@php.net>:
> > Hey Internals,
> >
> > I'm working on the patch to change the error exception to
> > \ArgumentCountError instead of \Error when too few, or too many arguments
> > are passed in as discussed a couple of weeks ago.
> >
> > To be BC with 7.0, this extends \TypeError, which is the exception
> > currently thrown when strict_types=1 for both userland and internal
> > functions.
> >
> > I've run into an issue where things are inconsistent for internal
> functions.
> >
> > For example, the array_* functions, like array_diff, still have a warning
> > thrown, regardless of strict_types:
> >
> > php_error_docref(NULL, E_WARNING, "at least %d parameters are required,
> %d
> > given", req_args, ZEND_NUM_ARGS());
>
> This seems more like an oversight than anything else, I guess cases
> with variable argument count may have some similar parameter parsing
> approaches. I think it should just be changed to the exception and to
> respect strict_types. Despite it being a BC break, I don't think that
> many will care to notice since its error handling for one and second
> of all, we did do that for a lot of things in 7.0, and I would assume
> that most of the userland developers expect us to continue converting
> into exceptions where reasonable, so the programs will *hopefully*
> quickly adapt.


I have completed this as best as I can tell. All test failures also exist
on master without the patch.

https://github.com/php/php-src/pull/2092

The only potential issue is that the format of the warning message has
changed slightly from e.g.:

-Warning: array_diff(): at least 2 parameters are required, 0 given in %s
on line %d
+Warning: array_diff() expects at least 2 parameters, 0 given in %s on line
%d

I suspect there are other functions that are not array functions that emit
similar warnings (especially for functions that expect _exact_ number of
arguments) that I missed, so if you know any of these, please let me know
and I'll update the patch.

If everyone is good with this I will merge down to PHP 7.1 for RC1 next
week.

- Davey

Re: [PHP-DEV] SQLite 3.14

[Davey Shafik]

Argh! Apologies for autocomplete adding that 'e' to your name!

- Davey

On Sat, Aug 20, 2016 at 03:09 Davey Shafik <da...@php.net> wrote:

> Christophe,
>
> I got the failure multiple times in my Debian Jessie docker container that
> I use for builds - you can check it out yourself at
> https://github.com/dshafik/php-build to see the setup.
>
> Thanks for looking into this!
>
> - Davey
> On Sat, Aug 20, 2016 at 01:35 Christoph M. Becker <cmbecke...@gmx.de>
> wrote:
>
>> Hi Davey!
>>
>> On 19.08.2016 at 15:32, Davey Shafik wrote:
>>
>> > I saw this failure while packaging 7.1.0beta3, and assume it might be
>> > related to your update:
>> >
>> > FAIL SQLite3 open_basedir checks
>> > [ext/sqlite3/tests/sqlite3_21_security.phpt]
>> >
>> > DIFF
>> > 006-
>> > 007- Warning: SQLite3::__construct(): open_basedir restriction in
>> effect.
>> > File(%s) is not within the allowed path(s): (.) in
>> > %ssqlite3_21_security.php on line %d
>> > 008- Exception: open_basedir prohibits opening %s in
>> > %ssqlite3_21_security.php:%d
>> > 009- Stack trace:
>> > 010- #0 %ssqlite3_21_security.php(%d): SQLite3->__construct('%s')
>> > 011- #1 {main}
>> > DONE
>> >
>> > Can you please look into this in time for RC1?
>>
>> I've just checked again with the tagged PHP-7.1.0beta3, but the test
>> succeeds on my machine.  Therefore it's hard for me to assess what is
>> wrong.  According to the diff, it appears that the second DB which
>> shouldn't be created according to the open_basedir restriction, is
>> actually successfully created.
>>
>> Anyway, it's rather unlikely that an open_basedir related failure is
>> caused by updating SQLite, as this check is part of the PHP binding[1],
>> which has not been affected by this commit.  The issue might be caused
>> by commit cc125f27[2], but that's also somewhat unlikely, because the
>> Travis checks usually succeed generally.
>>
>> Can you reproduce the test failure?  In which enviroment?
>>
>> [1] <https://github.com/php/php-src/blob/PHP-7.1.0beta3/ext/sqlite3
>> /sqlite3.c#L125
>> <https://github.com/php/php-src/blob/PHP-7.1.0beta3/ext/sqlite3/sqlite3.c#L125>
>> >
>> [2] <https://github.com/php/php-src/commit/cc125f27>
>>
>> --
>> Christoph M. Becker
>>
>

Re: [PHP-DEV] SQLite 3.14

[Davey Shafik]

Christophe,

I got the failure multiple times in my Debian Jessie docker container that
I use for builds - you can check it out yourself at
https://github.com/dshafik/php-build to see the setup.

Thanks for looking into this!

- Davey
On Sat, Aug 20, 2016 at 01:35 Christoph M. Becker <cmbecke...@gmx.de> wrote:

> Hi Davey!
>
> On 19.08.2016 at 15:32, Davey Shafik wrote:
>
> > I saw this failure while packaging 7.1.0beta3, and assume it might be
> > related to your update:
> >
> > FAIL SQLite3 open_basedir checks
> > [ext/sqlite3/tests/sqlite3_21_security.phpt]
> >
> > DIFF
> > 006-
> > 007- Warning: SQLite3::__construct(): open_basedir restriction in effect.
> > File(%s) is not within the allowed path(s): (.) in
> > %ssqlite3_21_security.php on line %d
> > 008- Exception: open_basedir prohibits opening %s in
> > %ssqlite3_21_security.php:%d
> > 009- Stack trace:
> > 010- #0 %ssqlite3_21_security.php(%d): SQLite3->__construct('%s')
> > 011- #1 {main}
> > DONE
> >
> > Can you please look into this in time for RC1?
>
> I've just checked again with the tagged PHP-7.1.0beta3, but the test
> succeeds on my machine.  Therefore it's hard for me to assess what is
> wrong.  According to the diff, it appears that the second DB which
> shouldn't be created according to the open_basedir restriction, is
> actually successfully created.
>
> Anyway, it's rather unlikely that an open_basedir related failure is
> caused by updating SQLite, as this check is part of the PHP binding[1],
> which has not been affected by this commit.  The issue might be caused
> by commit cc125f27[2], but that's also somewhat unlikely, because the
> Travis checks usually succeed generally.
>
> Can you reproduce the test failure?  In which enviroment?
>
> [1] <https://github.com/php/php-src/blob/PHP-7.1.0beta3/ext/sqlite3
> /sqlite3.c#L125
> <https://github.com/php/php-src/blob/PHP-7.1.0beta3/ext/sqlite3/sqlite3.c#L125>
> >
> [2] <https://github.com/php/php-src/commit/cc125f27>
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] SQLite 3.14

[Davey Shafik]

Hey Christoph,

I saw this failure while packaging 7.1.0beta3, and assume it might be
related to your update:

FAIL SQLite3 open_basedir checks
[ext/sqlite3/tests/sqlite3_21_security.phpt]

DIFF
006-
007- Warning: SQLite3::__construct(): open_basedir restriction in effect.
File(%s) is not within the allowed path(s): (.) in
%ssqlite3_21_security.php on line %d
008- Exception: open_basedir prohibits opening %s in
%ssqlite3_21_security.php:%d
009- Stack trace:
010- #0 %ssqlite3_21_security.php(%d): SQLite3->__construct('%s')
011- #1 {main}
DONE

Can you please look into this in time for RC1?

Thanks,

- Davey

On Thu, Aug 11, 2016 at 12:08 AM, Christoph M. Becker 
wrote:

> On 10.08.2016 at 16:01, Anatol Belski wrote:
>
> > Hi Christoph,
> >
> >> -Original Message-
> >> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> >> Sent: Monday, August 8, 2016 11:23 PM
> >> To: internals@lists.php.net; Anatol Belski 
> >> Subject: [PHP-DEV] SQLite 3.14
> >>
> >> Hi!
> >>
> >> SQLite 3.14 has been released today.  It brings some improvements and
> new
> >> features, and fixes a few bugs, see
> >> .
> >>
> >> I think PHP-7.1 should be updated, but I'm not sure about PHP-7.0, even
> though I
> >> found no regression when running the sqlite3 and pdo_sqlite test suites
> with
> >> 3.14 on Linux and Windows under a current PHP-7.0.
> >>
> >> Anatol, what do you think?
> >>
> > As long as 7.1 is still in pre cycle, it'd be cheap to upgrade there
> first. If there are no issues, we're safer to backport this SQLite version
> into a lower PHP branch.
>
> Sounds reasonable, Anotol.  Thanks.  So I'm going to update 7.1+ ASAP.
>
> --
> Christoph M. Becker
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] Incorrect Argument Count Error

[Davey Shafik]

Hey Internals,

I'm working on the patch to change the error exception to
\ArgumentCountError instead of \Error when too few, or too many arguments
are passed in as discussed a couple of weeks ago.

To be BC with 7.0, this extends \TypeError, which is the exception
currently thrown when strict_types=1 for both userland and internal
functions.

I've run into an issue where things are inconsistent for internal functions.

For example, the array_* functions, like array_diff, still have a warning
thrown, regardless of strict_types:

php_error_docref(NULL, E_WARNING, "at least %d parameters are required, %d
given", req_args, ZEND_NUM_ARGS());

It seems that fixing this will be:

a) a mammoth task

b) a huge BC break (stuff that currently throws a warning in strict_types
mode will now throw an exception, similar BC break as we're implementing
for userland functions regardless of strict_types)

c) something we should have done for 7.0, and that we cannot change now.

We are currently heading in 7.1.0RC1 in two weeks, and I want this issue
resolved in its entirety before then.

What say you, internals?

- Davey

Re: [PHP-DEV] Change to Too Few Args Exception RFC

[Davey Shafik]

Hey all,

Can we please reach a resolution on this?

- Davey

On Sun, Aug 7, 2016 at 9:04 AM, Davey Shafik <da...@php.net> wrote:

> AFAICT, to make this change, I'd have to modify:
>
> ZEND_API ZEND_COLD void zend_internal_type_error(zend_bool
> throw_exception, const char *format, ...) /* {{{ */
>
> To be:
>
> ZEND_API ZEND_COLD void zend_internal_type_error(zend_bool
> throw_exception, zend_class_entry *zend_error, const char *format, …) /*
> {{{ */
>
> Which… would be a BC break for extensions perhaps?
>
> There is also zend_type_error, I'm not sure how that relates, I don't
> think it gets used in this case. Or, I could add 
> zend_(internal_?)argument_count_error
> and use that instead.
>
> Thoughts?
>
> - Davey
>
>
> On Sat, Aug 6, 2016 at 4:10 AM, Thomas Punt <tp...@hotmail.co.uk> wrote:
>
>> Hi!
>>
>> > From: m...@kelunik.com
>> >
>> > I don't like "ArgumentError", how about "WrongArgumentCountError"? Maybe
>> > also "WrongArgumentsError".
>>
>> I'd favour simply ArgumentCountError. No need to prepend a "wrong" to the
>> error class name - we can already guess it's wrong because it has
>> resulted in
>> an error :)
>>
>> -Tom
>>
>
>

Re: [PHP-DEV] BC break with rand() where min > max

[Davey Shafik]

Leigh,

I would _very_ much prefer to keep this BC. If we do the right thing, and
there are no repercussions, I'd actually remove the warning. If you think
we might want to disallow this in the future, use an E_DEPRECATED, but a
warning seems pointless unless it's doing the wrong thing, or it's going to
start doing the wrong thing at some point.

- Davey

On Mon, Aug 8, 2016 at 2:36 PM, Leigh  wrote:

> Hi all,
>
> There has been an unforeseen break with rand() when the minimum value is
> greater than the maximum.
>
> Prior to 7.1 rand() would happily accept backwards parameters and return a
> value, however in the 7.1 branch it now emits a warning and returns false.
>
> I've preemptively committed a fix to allow min > max and return a value as
> in previous versions, but have kept the warning.
>
> Looking for some feedback/opinions on whether anyone else thinks this
> should be fixed differently (or not at all).
>
> N.B. this also changes the behaviour of mt_rand to now accept min > max
>

Re: [PHP-DEV] Function auto-loading

[Davey Shafik]

On Mon, Aug 8, 2016 at 1:15 PM, Rasmus Schultz  wrote:

> > Unfortunately, function name resolution has this quirk that class name
> resolution doesn't, so something's got to give.
>
> I suppose.
>
> Well, then, how about making the feature work consistently for all
> functions, by coupling it directly to the "use function" statement?
>
> In other words, the feature changes from being strictly about auto-loading
> functions, to instead resolving an imported function - so it would be
> triggered by the "use function" statement only, rather than by the use of
> the function, and the resolved function pertains only to the scope of the
> file.
>
> A function resolver would simply need to return a callable:
>
> register_function_resolver(function ($name) {
> if ($name === "html") {
> return function ($str) {
> return htmlspecialchars($str, ENT_HTML5);
> };
> }
>
> if (substr($name, 0, 5) === "iter\\") {
> require_once VENDOR_PATH."/nikic/iter/src/bootstrap.php";
> return $name;
> }
> });
>
> This mechanism is probably a lot easier to explain and understand - and
> works equally for global or namespaced functions.
>
> It also lets you potentially do other weird shit, like overriding
> var_dump() or hooking into certain function calls - which could enable you
> to do a bunch of evil, but I'm not really big on complicating features
> solely to keep users from doing harm; simpler language features tend to
> allow you to do more stuff - good or evil.
>
> Likely the 99% use-case is simply for Composer to bootstrap your packages
> for you, and this feature will permit you to do that.
>
> Okay, so it doesn't deal with namespaced constants, and maybe this is me
> being opinionated, but who's going to import constants one by one?
> Constants are usually better off grouped together in a class. Although I
> don't suppose there's any reason this concept couldn't be expanded to work
> for constants as well, for completeness at least - though I have doubts
> that very many people would care...
>
> Anyways, just spitballing here :-)
>
>
> On Mon, Aug 8, 2016 at 7:54 PM, Rowan Collins 
> wrote:
>
> > On 08/08/2016 18:03, Levi Morrison wrote:
> >
> >> If not, I don't see why we ever need to be able to autoload global
> >> functions. "You want autoloading? Put it in a namespace." Like I
> >> say, that leaves the very small edge case of a single namespace
> >> spanning multiple files, and an autoloader implementation able to
> >> include one of them when a function is called from another.
> >>
> >>
> >> I'm not sure why you would think a single namespace spanning multiple
> >> files is a "very small edge case". I disagree. Here are some libraries I
> >> am aware of *off the top of my head* that use functions the same
> >> namespace across multiple files:
> >>
> >>   * https://github.com/nikic/iter
> >>   * https://github.com/lstrojny/functional-php
> >>
> >> As well as several of my personal projects. I do not think this is a
> >> "very small edge case."
> >>
> >
> > The "iter" example looks a long way from being autoloadable whatever we
> > supported, but the example of one-function-per-file is definitely
> relevant,
> > so I stand corrected.
> >
> > After a bit of clicking, I even managed to find a line which would fail
> to
> > autoload under the proposed limitation:
> >
> > https://github.com/lstrojny/functional-php/blob/master/src/
> > Functional/CompareObjectHashOn.php
> >
> > > return compare_on($comparison, $keyFunction);
> >
> > Although interestingly, at the top of the file there is a (technically
> > unnecessary) "use function Functional\compose;" If there was a "use
> > function Functional\compare_on;" as well, we'd be fine. (The function
> name
> > would then become qualified at compile time and trigger autoloading at
> run
> > time.)
> >
> >
> > On 08/08/2016 18:06, Rasmus Schultz wrote:
> > > Unless there's a demonstrated, critical performance issue with
> > > auto-loading of global functions, please, let's not cripple this
> feature
> > > with inconsistencies from the get-go!
> >
> > Sure, we could try to measure it, but remember that it's not just the
> > engine code that has the extra cost, it will actually call a userland
> > function every time you use a global function from inside a namespace if
> > you don't add a leading "\". That userland function will probably do a
> > bunch of string comparisons before deciding it's not interested, and may
> > even try to stat a file or two. Those are really expensive operations,
> so I
> > think it's a long way from "micro-optimisation".
> >
> > Unfortunately, function name resolution has this quirk that class name
> > resolution doesn't, so something's got to give.
> >
> >
> > Regards,
>

Related to this, I'd like to see stream (and stream filter) autoloading.
Essentially, if you fopen("random://foo")  

Re: [PHP-DEV] Function auto-loading

[Davey Shafik]

On Sun, Aug 7, 2016 at 12:32 PM, David Rodrigues 
wrote:

> What should be the difference between a static method on a autoloaded
> class?
>
> I guess that it could be done currently by use a static method.
> In this case, I know exactly what method should be called, without
> depends of an autoloader response.
>
> class String {
> public static function strpos(...) { ... }
> }
>
> In this case, I just need to call String::strpos(...) and done.
>
> I don't know if I'm missing something.
>
> 2016-08-07 9:07 GMT-03:00 Rasmus Schultz :
> > Of course calling e.g. strpos() should not trigger the auto-loader
> > repeatedly - can we cache the information that the auto-loader was
> > attempted once during the current script execution? so that e.g. only the
> > first call to strpos() triggers the auto-loader?
> >
> > I suppose it would still happen once for every namespace from which
> > strpos() gets called, so maybe this optimization doesn't help much.
> >
> > I guess I'd say, benchmark it before making assumptions? Maybe the
> > performance hit turns out to be negligible in practice. Hard to say.
> >
> > If a performance hit is inevitable, but marginal, I hope that we do not
> let
> > micro-benchmarks stand in the way of improving the language?
> >
> > With PHP 7, the language is in many ways almost twice as fast as it was
> > before. I think it's fair to say, PHP has problems that are much bigger
> > than performance - to most developers, performance is not a pain point
> > anymore, if it was before PHP 7.
> >
> > I wish that I could change your focus from performance concerns to
> actually
> > focusing on the language itself.
> >
> > It seems that me that recent performance improvements have become
> somewhat
> > of a bottleneck that *prevents* new features and (worse) missing features
> > from completing and improving the language?
> >
> > The performance improvements could just as well be viewed as a factor
> that
> > creates new elbow room for new features and language improvements, which,
> > long term, likely have much more value to more developers than the
> > performance of micro-benchmarks.
> >
> > At the end of the day, for like 9 our of 10 projects, PHP's core
> > performance is not the bottleneck - things like database queries are. The
> > cost of developing a project is also generally unrelated to core
> > performance of the language. Hardware gets cheaper and faster every day.
> So
> > who or what are we optimizing for?
> >
> > I don't mean to get too side-tracked from the original conversation here,
> > but we should be designing for developers - not for machines. The
> language
> > is more than fast enough for what most developers need it for - and still
> > nowhere near fast enough for, say, a JSON or XML parser, the kind of
> things
> > that require C or assembly level performance, and I really don't believe
> > there's a substantial segment of use-cases that fall in between - for
> most
> > things, either you need performance that PHP can't get near, or you need
> > language features and convenience that low-level languages can't deliver.
> >
> > We're not competing with C - and if we're competing with other scripting
> > languages on performance, we're already in a pretty good position, and
> > people who select a scripting language aren't basing their choice on raw
> > performance in the first place; if that was their concern, they'd pick C.
> >
> > We should focus on competing with other scripting languages on features,
> > convenience, productivity, etc. - if our main concern is competing on
> > low-level concerns like performance, those concerns will override the
> > points that really matter to developers who choose a high-level scripting
> > language, and we will lose.
> >
> >
> > On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov 
> wrote:
> >
> >> On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz 
> wrote:
> >>
> >>> I'd really like to see the function auto-loading proposal revived
> and/or
> >>> possibly simplified.
> >>>
> >>> The fact that functions are hard (in some cases impossible) to reach by
> >>> manually issuing require/include statements is, in my opinion, half the
> >>> difficulty, and a much more deeply rooted language problem exacerbating
> >>> what should be trivial problems - e.g. install a Composer package,
> import
> >>> (use) and call the functions.
> >>>
> >>> Looks like a fair amount of work and discussion was done in 2013 on
> this
> >>> RFC:
> >>>
> >>> https://wiki.php.net/rfc/function_autoloading
> >>>
> >>> There was a (now stale) proof of concept implementation for the parent
> RFC
> >>> as well:
> >>>
> >>> https://wiki.php.net/rfc/function_autoloading2
> >>>
> >>> What happened?
> >>>
> >>> It looks like the discussion stalled mostly over some concerns,
> including
> >>> reservations about performance, which were already disproved?
> >>>
> >>> One issue apparently was left 

Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version?

[Davey Shafik]

On Sun, Aug 7, 2016 at 8:20 AM, Niklas Keller  wrote:

> 2016-08-07 14:20 GMT+02:00 Pierre Joye :
>
> > On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki"  wrote:
> > >
> > > Hi Christian,
> > >
> > > On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler 
> wrote:
> > > > Am 04.08.2016 um 12:10 schrieb Yasuo Ohgaki:
> > > >> Hi Christian and all,
> > > >>
> > > >> On Thu, Aug 4, 2016 at 10:07 AM, Christian Stadler 
> > wrote:
> > > >>> Am 01.08.2016 um 10:23 schrieb Yasuo Ohgaki:
> > >  P.S. It's possible to return array that contains offending values.
> > It
> > >  is not included since users can store whole offending input array.
> > >  Whole input is more useful for attack analysis.
> > > >>> Actually I wanted to suggest exactly that for ppl. who want to give
> > > >>> Feedback to their users, what values failed to validate to the
> users.
> > > >>> Probably with a fourth optional param, like `$return_invalid =
> > false`?
> > > >>> Of course logging is a different topic and should always use the
> > whole
> > > >>> offending input array.
> > > >> I can set offending value to filter globals so that it can be
> > > >> retrieved later in catch block. I cannot return or modify referenced
> > > >> parameter because of raised exception.
> > > >
> > > > Well, since some people have objections about raising exceptions
> here,
> > > > this should probably be either in a seperate vote or additional
> options
> > > > in the main vote. Probably something, like:
> > > > Yes, either | Yes, without the exception | Yes, with the exception |
> No
> > > > Personally I would vote for 'Yes, either'. If I could, that is.
> > >
> > > One of my objective is following best practices.
> > > Prefer exception over error is one of them. Although, I strongly
> suggest
> > > to use exception for validation errors, I will have choices.
> >
> > I see them as conditions flow not errors per se but flow.
> >
> > Invalid options could raise exceptions but it brings inconcistencies with
> > the other filter functions.
> >
> > I feel like this rfc needs more discussions and maybe we will add more
> > things to filter as well.
> >
> > But anything proposed is already possible very easily in userland. I
> would
> > not rush it into 7.1.
> >
>
> Isn't it a bit late to target 7.1 anyway?
>

Yes, it is much too late for 7.1, this will have to be targeted towards 7.2+

- Davey

Re: [PHP-DEV] Undocumented Nullable Return Behavior

[Davey Shafik]

Nikita,

Just to confirm for explicitness-sake:

> Nullable return types work inversely to void return types. You must
return either the specified type, or an explicit null. Anything else is
either a TypeError (incorrect type [implicitly] returned), or a [compile
time] fatal error (return without value).

Is it worthwhile updating the RFC with this information and examples as it
is most likely what will be used to create documentation (if it's not been
documented already) and the spec.

I'm happy to do that, if that's desired.

- Davey

On Sun, Aug 7, 2016 at 12:58 AM, Nikita Popov <nikita@gmail.com> wrote:

> On Sun, Aug 7, 2016 at 9:07 AM, Davey Shafik <m...@daveyshafik.com> wrote:
>
>> Hi internals,
>>
>> In the nullable types we do not allow implicit return null/return with no
>> value to fulfill a nullable type.
>>
>> - No return will result in a TypeError when executed
>> - Return with no value will be an actual fatal error, which I believe is
>> due to the fact it's not found at runtime, should be a TypeError or
>> ParseError if possible?
>>
>
> It's a compile time error. Compile time errors are currently fatal errors
> for technical reasons.
>
>
>> - Return explicit null is fine (as expected)
>>
>> See: https://3v4l.org/h6IYF
>>
>> I believe the first two are contrary to PHP's "null is always returned if
>> nothing else is".
>>
>> OTOH, it makes sense as it's the entire reasoning behind return void vs
>> return null.
>>
>
> Indeed. The current behavior is consistent with the (explicit decision
> from) the void RFC.
>
> Additionally, the current behavior is consistent with the behavior of the
> implementation at the time the RFC was voted, with the only difference that
> I have made this a compile-time error after the fact (because I think if we
> know that something will always result in a runtime error, we should try to
> detect it at compile-time already, and because the void error is detected
> at compile-time as well).
>
> Nikita
>
>
>> This behavior is completely undocumented in the RFC.
>>
>> It's definitely something we should make an explicit decision on for the
>> language spec if nothing else.
>>
>> We should also make any decisions on this prior to beta3 in < 2 weeks.
>>
>> Thoughts?
>>
>> - Davey
>>
>
>

[PHP-DEV] Undocumented Nullable Return Behavior

[Davey Shafik]

Hi internals,

In the nullable types we do not allow implicit return null/return with no
value to fulfill a nullable type.

- No return will result in a TypeError when executed
- Return with no value will be an actual fatal error, which I believe is
due to the fact it's not found at runtime, should be a TypeError or
ParseError if possible?
- Return explicit null is fine (as expected)

See: https://3v4l.org/h6IYF

I believe the first two are contrary to PHP's "null is always returned if
nothing else is".

OTOH, it makes sense as it's the entire reasoning behind return void vs
return null.

This behavior is completely undocumented in the RFC.

It's definitely something we should make an explicit decision on for the
language spec if nothing else.

We should also make any decisions on this prior to beta3 in < 2 weeks.

Thoughts?

- Davey

Re: [PHP-DEV] Change to Too Few Args Exception RFC

[Davey Shafik]

AFAICT, to make this change, I'd have to modify:

ZEND_API ZEND_COLD void zend_internal_type_error(zend_bool throw_exception,
const char *format, ...) /* {{{ */

To be:

ZEND_API ZEND_COLD void zend_internal_type_error(zend_bool throw_exception,
zend_class_entry *zend_error, const char *format, …) /* {{{ */

Which… would be a BC break for extensions perhaps?

There is also zend_type_error, I'm not sure how that relates, I don't think
it gets used in this case. Or, I could add
zend_(internal_?)argument_count_error and use that instead.

Thoughts?

- Davey


On Sat, Aug 6, 2016 at 4:10 AM, Thomas Punt  wrote:

> Hi!
>
> > From: m...@kelunik.com
> >
> > I don't like "ArgumentError", how about "WrongArgumentCountError"? Maybe
> > also "WrongArgumentsError".
>
> I'd favour simply ArgumentCountError. No need to prepend a "wrong" to the
> error class name - we can already guess it's wrong because it has resulted
> in
> an error :)
>
> -Tom
>

Re: [PHP-DEV] Change to Too Few Args Exception RFC

[Davey Shafik]

On Sat, Aug 6, 2016 at 2:34 AM, Nikita Popov <nikita@gmail.com> wrote:

> On Sat, Aug 6, 2016 at 4:26 AM, Davey Shafik <da...@php.net> wrote:
>
>> Hey all,
>>
>> I know this is a little late in the process, but it's something I've
>> noticed while prepping some content around 7.1.
>>
>> This RFC: https://wiki.php.net/rfc/too_few_args
>>
>> Passed, and has been implemented, but I feel that throwing an `\Error`
>> exception is a mistake. I think we should another more concrete exception
>> class for this error:
>>
>> `\TooFewArgumentsError extends \Error`
>>
>> A use case where this may trivially occur is where you are using argument
>> unpacking and the unpacked array is too small. Writing this, just looks
>> bad:
>>
>> try {
>>foo(… $args);
>> } catch (\Error $e) { }
>>
>> compared:
>>
>> try {
>>foo(… $args);
>> } catch (\TooFewArgumentsError $e) { }
>>
>> Thoughts? Dmitry?
>>
>> Given the tiny change this is, and that is backwards compatible with the
>> original RFC, I would like to add this to 7.1 for beta3.
>>
>> I think I can make this change myself.
>>
>> - Davey
>>
>
> Problem: We already use TypeError for this for internal functions. If we
> want to introduce an extra exception for this, lets use it for internal
> functions as well. In that case we should probably go with something that
> applies not just to too few arguments, but also to too many.
>

Are you saying that in PHP 7.0, if you call an internal function with too
few, or too many arguments it will emit a TypeError exception?

Can you provide examples? It's obviously not every function, e.g. fopen()
emits a Warning if you forget the second arg.

With that in mind, to make this BC, TooFewArguments would have to extend
TypeError which isn't great.  Maybe, "ArgumentError" and the message will
make it clear if it's too few or too many?

- Davey

Re: [PHP-DEV] Re: Change to Too Few Args Exception RFC

[Davey Shafik]

Dmitry,

I've tried to implement this myself, and it seems to work fine, but I end
up with some weird (unrelated?) test failures after:

https://github.com/php/php-src/compare/master...dshafik:too-few-args-exception

Example test failure:

DIFF
001+ Warning: file_get_contents(http://localhost:8964): failed to open
stream: Connection refused in /Users/dshafik/src/
php.net/php-src/tests/basic/bug67198.php on line 29
002+ bool(false)
001- string(4) "PASS"
002- string(4) "PASS"
003+
004+ Warning: file_get_contents(http://localhost:8964): failed to open
stream: Connection refused in /Users/dshafik/src/
php.net/php-src/tests/basic/bug67198.php on line 30
005+ bool(false)
DONE
FAIL php://input is empty when enable_post_data_reading=Off
[tests/basic/bug67198.phpt]

and:

DIFF
001+ Warning: Declaration of melt\core\DateTime::createFromFormat($format,
$time, ?melt\core\DateTimeZone $timezone = NULL) should be compatible with
DateTime::createFromFormat($format, $time, $object = NULL) in
/Users/dshafik/src/php.net/php-src/ext/date/tests/bug55407.php on line 7
DONE

List of failed tests:

=
FAILED TEST SUMMARY
-
Test posix_getgrgid() function : basic functionality
[ext/posix/tests/posix_getgrgid_basic.phpt]
Test chdir() function : basic functionality
[ext/standard/tests/dir/chdir_basic-win32-mb.phpt]
Test chdir() function : usage variations - relative paths
[ext/standard/tests/dir/chdir_variation2-win32-mb.phpt]
Test getcwd() function : basic functionality
[ext/standard/tests/dir/getcwd_basic-win32-mb.phpt]
Test readdir() function : usage variations - sub-directories
[ext/standard/tests/dir/readdir_variation3-win32-mb.phpt]
Test readdir() function : usage variations - different file names
[ext/standard/tests/dir/readdir_variation4-win32-mb.phpt]
Test readdir() function : usage variations - operate on previously opened
directory [ext/standard/tests/dir/readdir_variation6-win32-mb.phpt]
Test rewinddir() function : basic functionality
[ext/standard/tests/dir/rewinddir_basic-win32-mb.phpt]
Test scandir() function : basic functionality
[ext/standard/tests/dir/scandir_basic-win32-mb.phpt]
Test scandir() function : usage variations - different sorting constants
[ext/standard/tests/dir/scandir_variation10-win32-mb.phpt]
Test scandir() function : usage variations - different relative paths
[ext/standard/tests/dir/scandir_variation4-win32-mb.phpt]
Test scandir() function : usage variations - different file names
[ext/standard/tests/dir/scandir_variation8-win32-mb.phpt]
Test scandir() function : usage variations - different ints as
$sorting_order arg [ext/standard/tests/dir/scandir_variation9-win32-mb.phpt]
file_get_contents() test using offset parameter out of range
[ext/standard/tests/file/file_get_contents_error001.phpt]
Test lstat() and stat() functions: usage variations - file opened using w
and r mode [ext/standard/tests/file/lstat_stat_variation13.phpt]
Check cli_process_title support on Unix
[sapi/cli/tests/cli_process_title_unix.phpt]
=

I can't see how my change has affected this at all; but maybe I missed
something?

Could you review and see if you spot anything?

Thanks,

On Sat, Aug 6, 2016 at 12:33 AM, Joe Watkins <pthre...@pthreads.org> wrote:

> Morning all,
>
>Good idea, +1 for just doing it ...
>
> Cheers
> Joe
>
> On Sat, Aug 6, 2016 at 8:18 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>> I don't see a big problem accepting this. The change is really minor, and
>> makes sense.
>>
>> Dmitry.
>>
>> On Aug 6, 2016 5:26 AM, Davey Shafik <da...@php.net> wrote:
>> Hey all,
>>
>> I know this is a little late in the process, but it's something I've
>> noticed while prepping some content around 7.1.
>>
>> This RFC: https://wiki.php.net/rfc/too_few_args
>>
>> Passed, and has been implemented, but I feel that throwing an `\Error`
>> exception is a mistake. I think we should another more concrete exception
>> class for this error:
>>
>> `\TooFewArgumentsError extends \Error`
>>
>> A use case where this may trivially occur is where you are using argument
>> unpacking and the unpacked array is too small. Writing this, just looks bad:
>>
>> try {
>>foo(… $args);
>> } catch (\Error $e) { }
>>
>> compared:
>>
>> try {
>>foo(… $args);
>> } catch (\TooFewArgumentsError $e) { }
>>
>> Thoughts? Dmitry?
>>
>> Given the tiny change this is, and that is backwards compatible with the
>> original RFC, I would like to add this to 7.1 for beta3.
>>
>> I think I can make this change myself.
>>
>> - Davey
>>
>>
>>
>>
>

[PHP-DEV] PHP 7.1.0beta2 is available for testing

[Davey Shafik]

Hi,

PHP 7.1.0beta2 was just released and can be downloaded from:

https://downloads.php.net/~davey/

The Windows binaries are available at

http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please refer
to the NEWS file:

https://github.com/php/php-src/blob/php-7.1.0beta2/NEWS

Please test it carefully, and report any bugs in the bug system.

The next release will be 7.1.0beta3 on August 18th. Beta 3 will be the last
beta before go to RC1.

Below is the verification information for the downloads:

php-7.1.0beta2.tar.bz2
SHA256 hash:
c6de355bb7ee7a98326807e92ef6d99a7019d75f66c779af15c4a4d149005664
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXpQYAAAoJEGWqzKLMO04m1KUH/jxs7nNnwNNCR+KU/WuJ1oTJ
4KrUNvFnlnv+lVw+tnFsUwv4QDgURRrIZuZ+Il1eQzZOXkXrV05FFXAsY/oT34vF
kQFA9UiDf3j23I1ZL2PgFPSiGaTKpmkWQOoXkvROHR7HhGyceU5xAzYPv39vHMah
t3Sf8GOdrTQ2LUS6nUAqHXB2xtSlMM/pefew7Gv4yV7U23KhWlMhkIexZkQFVhwx
GQuXo9z2ztpD1c3G7VFIWpa5FYjzttg87WwmrcAwn1rM+nSb1aoFjdxDNIg3E6Cp
qCR17n0r8OiJIg+ipg8WXGlu6VG574YDbCY0iCXLGeyJzf/2vYlue55/12JHhAs=
=DSQa
-END PGP SIGNATURE-


php-7.1.0beta2.tar.gz
SHA256 hash:
2a09aacc3eff60fef14e8b5bd1637da87a935422d23c300d75df035f33e42919
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXpQdhAAoJEGWqzKLMO04mlp4H/j7vLQkvIYjrF6MyphgXo+be
d5bgGs1AlOkZUJXtopgUhnMRo62f6CLElPyJrVukbvJKFWp8Xt0VZ4UQEQkS7MQ4
3O+Q0g9F58TICo/CiC9sg0r69Y+mnSxPZcg/a3JaHByeDP21kcnpDNmvAIwUcd8T
OmVKmHb6CThKqlnUF4Kv49a8VeHKJU7cq9PXMFySRU2TwWeQ+NA7L8hpKA3pZ1Vd
xVTIdluZsyyQJ/ICXJasD7r5x9mCq7E4K5RG81UJrA/plbLQZxIW7tGDzhB04rYb
Bprwwz3g10PI8pUJRmS9pp+c8/quHJkndBc24mNX5mIhiiHDgdBiU474kF3Q4Ec=
=04g2
-END PGP SIGNATURE-


php-7.1.0beta2.tar.xz
SHA256 hash:
73fecbcc73605aab0c85c490bc2fed8514bdecb6716aa9c0baba6b6f5d7ea89a
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXpQdiAAoJEGWqzKLMO04m5g0H/jzaA3VYKYrGVOf9UBfrE7o4
5/uZN2vlVj+aKptVRAaxGs8wvZRZGInuoaQjOOmei9RfhfG2YwDEpZS3EJPN95yk
F5776mG/6/KrVtGhveo5x3RSkYOiXYv82t9cL1u1FAIz6g1tVTGa1oae+TmBx9kt
yCOUBbriPTPkDC7ds+72/vYd0G6LFRKohaNkev8weYO0G7r0uueWxzAKfl3CTDbQ
nmqTcxLhKE3yKYJyy+YZhiqzXO3gYUi6wsV+nlnyFQjI3T/ySANJ1yKXG+bS0m+l
xllp/V+dlDut0ZDrO+aRrRmziVnHUAomVsUfFgpcdjGV+Z8+Ln/PoZTmg5KqN7Q=
=Y4zb
-END PGP SIGNATURE-

[PHP-DEV] Change to Too Few Args Exception RFC

[Davey Shafik]

Hey all,

I know this is a little late in the process, but it's something I've
noticed while prepping some content around 7.1.

This RFC: https://wiki.php.net/rfc/too_few_args

Passed, and has been implemented, but I feel that throwing an `\Error`
exception is a mistake. I think we should another more concrete exception
class for this error:

`\TooFewArgumentsError extends \Error`

A use case where this may trivially occur is where you are using argument
unpacking and the unpacked array is too small. Writing this, just looks bad:

try {
   foo(… $args);
} catch (\Error $e) { }

compared:

try {
   foo(… $args);
} catch (\TooFewArgumentsError $e) { }

Thoughts? Dmitry?

Given the tiny change this is, and that is backwards compatible with the
original RFC, I would like to add this to 7.1 for beta3.

I think I can make this change myself.

- Davey

Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing - Vote reopened and restarted

[Davey Shafik]

Hey Yasuo,

Unfortunately this missed beta2 (tagged yesterday), I'll confirm with Joe
about putting it in for 7.1beta3.

Thanks for those last minute changes, I'm much happier with this result! :)

- Davey

On Tue, Aug 2, 2016 at 10:29 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> Session ID without hashing
> https://wiki.php.net/rfc/session-id-without-hashing#vote
>
> This RFC is passed 9 vs 0.
> Compatible default is used as default. 7 vs 3.
>
> It needs to update the default INI. I'll finish it in a few days.
>
> Thank you for voting!
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
> On Mon, Jul 25, 2016 at 6:49 PM, Yasuo Ohgaki  wrote:
> > Hi all,
> >
> > Due to defects in the RFC, vote is reopened and restarted.
> > Followings are changes from 1st vote.
> >
> >  - Removed session.use_strict_mode change
> >(Changed when vote reopened)
> >  - Added INI default vote options, incompatible and compatible.
> >(Changed when 2nd vote is restarted)
> >  - Extended vote period for 2 days.
> >
> > These who are voted already have to **VOTE AGAIN**.
> > Sorry for the inconvenience and confusion!
> >
> > 
> >
> > Currently session module uses obsolete MD5 for session ID. With
> > CSPRNG, hashing is redundant and needless. It adds hash module
> > dependency and inefficient.
> >
> > This proposal cleans up session code by removing hash.
> >
> > https://wiki.php.net/rfc/session-id-without-hashing
> >
> > I set vote requires 2/3 support.
> > Please describe the reason why when you against this RFC. Reasons are
> > important for improvements!
> >
> > Vote ends 2016/08/02 23:59:59 UTC.
> >
> > Thank you for voting!
> >
> > --
> > 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] New operator (short tag) for context-dependent escaping

[Davey Shafik]

This should definitely be a 2 week vote.

- Davey
On Sat, Jul 30, 2016 at 08:09 Michael Vostrikov 
wrote:

> Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
> now in voting phase.
>
> https://wiki.php.net/rfc/escaping_operator
>
> This RFC introduces new short tag/operator, which will perform echo with an
> automatic call of escaping function.
> Voting is open till August 6, but it can be prolongated if you will decide
> that this is too small voting time for such a change.
> Voting requires 2/3 support.
>
> Thank you for voting.
>

Re: [PHP-DEV] RFC Karma Request

[Davey Shafik]

Ah, I missed that. If we had ranges (e.g. $string[0..4] or $string[-1..4])
that'd work, but we don't.

Now I see some value in the function, though still perhaps not enough to
justify above and beyond strpos etc.


On Tue, Jul 26, 2016 at 5:11 PM, <w...@wkhudgins.info> wrote:

> Davey,
>
> Thanks for joining the conversation! That code snippet is very elegant,
> and it is a superb way of checking if a string starts with or ends with a
> specific character. However, it does not check if a string starts with or
> ends with a specific string, containing multiple characters.
>
> True str_begins and str_ends would do check if a string begins or ends
> with a string of n characters.
>
> Regards,
>
> -Will
>
>
> On 2016-07-26 19:39, Davey Shafik wrote:
>
>> Will,
>>
>> Now that we have generalized support for negative string offsets you
>> can now just do:
>>
>> $string = "/foo/bar/bat/";
>> if ($string[0] === "/") { // fully-qualified path }
>> if ($string[-1] === "/") { // trailing "/" }
>>
>> This avoids the overhead of a function call, arguably is as
>> expressive, and a lot more functional (e.g. offset -2).
>>
>> - Davey
>>
>> On Tue, Jul 26, 2016 at 2:27 PM, <w...@wkhudgins.info> wrote:
>>
>> Thanks for replying David.
>>>
>>> Thanks for the questions, its good to elaborate on things some. I'll
>>> address each question here:
>>>
>>> 1. No, I guess this is my first time reaching out to the community.
>>> I had gone with str_begins and str_ends because it fit some of the
>>> current naming approaches. I could see an argument for
>>> strstarts/strends, strbegins/strends, or startsWith/endsWith. I'm
>>> flexible with the exact naming.
>>>
>>> 2. I don't think performance-wise it would be a big improvement over
>>> using strpos, preg_match, or substr. However, I think it might be an
>>> improvement readability-wise. Right now people either use somewhat
>>> confusing code, like strpos or substr, or they implement their own
>>> user-defined str_starts function. I think the benefit in terms of
>>> readability and usability justifies the addition of two new
>>> functions to the namespace.
>>>
>>> 3. This functionality is doable with the current implementation.
>>> However, part of the goal of languages or tools is to make it easy
>>> to do common, routine tasks. Python, Java, Ruby, C# and JavaScript
>>> all provide this functionality. So I am sure people would find it
>>> useful in PHP.
>>>
>>> 4. Right now, the way I have it implemented, it is case-sensitive.
>>> If people wanted, it could be implemented to take an optional
>>> boolean parameter called case_sensitive which defaults to true. I
>>> could make that change pretty easily, if I did that the function
>>> headers would be:
>>>
>>> boolean str_starts (string $str , str $search_value [, bool
>>> $case_sensitive = true ] )
>>> boolean str_ends (string $str , str $search_value [, bool
>>> $case_sensitive = true ] )
>>>
>>> I like the idea of doing that instead of having separate,
>>> case-insensitive, functions because it helps keep the name space
>>> less cluttered.
>>>
>>> I hope this has provided some helpful information. Please get back
>>> with me with your thoughts.
>>>
>>> Thanks,
>>> Will
>>>
>>> On 2016-07-26 16:09, David Rodrigues wrote:
>>> Questions:
>>>
>>> 1.
>>> Have you talked with this list about the terms of you suggestions?
>>> (like str_begins, str_starts, strstarts, strbegins, str_ends,
>>> strends...)
>>> Is yes, sorry, I do not received this topic before.
>>>
>>> 2.
>>> There some valid performance advantage over strpos()?
>>>
>>> 3.
>>> And about the "market" for this new function?
>>> I mean, about users really need a new function like it on core.
>>>
>>> 4.
>>> And about the case sensitiblity?
>>> Should have some function like stribegins() or will be an argument?
>>>
>>> In general, I like this implementation, but I like to know about you
>>> in this questions.
>>> I don't know the policy about implements new functions on "str
>>> namespace".
>>>
>>> Thanks!
>>>
>>> 2016-07-26 15:41 GMT-03:00  <w...@wkhudgins.info>:
>>> Hello,
>>>
>>> I would like to submit an RFC for adding a str_begins and str_ends
>>> function,
>>> in relation to https://bugs.php.net/bug.php?id=67035 and
>>> https://bugs.php.net/bug.php?id=50434. I've added those functions on
>>> my
>>> local PHP copy. I would like to make an RFC and a PR for adding it
>>> to the
>>> core PHP copy.
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>> --
>>> 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] RFC Karma Request

[Davey Shafik]

Will,

Now that we have generalized support for negative string offsets you can
now just do:

$string = "/foo/bar/bat/";
if ($string[0] === "/") { // fully-qualified path }
if ($string[-1] === "/") { // trailing "/" }

This avoids the overhead of a function call, arguably is as expressive, and
a lot more functional (e.g. offset -2).

- Davey

On Tue, Jul 26, 2016 at 2:27 PM,  wrote:

> Thanks for replying David.
>
> Thanks for the questions, its good to elaborate on things some. I'll
> address each question here:
>
> 1. No, I guess this is my first time reaching out to the community. I had
> gone with str_begins and str_ends because it fit some of the current naming
> approaches. I could see an argument for strstarts/strends,
> strbegins/strends, or startsWith/endsWith. I'm flexible with the exact
> naming.
>
> 2. I don't think performance-wise it would be a big improvement over using
> strpos, preg_match, or substr. However, I think it might be an improvement
> readability-wise. Right now people either use somewhat confusing code, like
> strpos or substr, or they implement their own user-defined str_starts
> function. I think the benefit in terms of readability and usability
> justifies the addition of two new functions to the namespace.
>
> 3. This functionality is doable with the current implementation. However,
> part of the goal of languages or tools is to make it easy to do common,
> routine tasks. Python, Java, Ruby, C# and JavaScript all provide this
> functionality. So I am sure people would find it useful in PHP.
>
> 4. Right now, the way I have it implemented, it is case-sensitive. If
> people wanted, it could be implemented to take an optional boolean
> parameter called case_sensitive which defaults to true. I could make that
> change pretty easily, if I did that the function headers would be:
>
> boolean str_starts (string $str , str $search_value [, bool
> $case_sensitive = true ] )
> boolean str_ends (string $str , str $search_value [, bool $case_sensitive
> = true ] )
>
> I like the idea of doing that instead of having separate,
> case-insensitive, functions because it helps keep the name space less
> cluttered.
>
> I hope this has provided some helpful information. Please get back with me
> with your thoughts.
>
> Thanks,
> Will
>
>
> On 2016-07-26 16:09, David Rodrigues wrote:
>
>> Questions:
>>
>> 1.
>> Have you talked with this list about the terms of you suggestions?
>> (like str_begins, str_starts, strstarts, strbegins, str_ends,
>> strends...)
>> Is yes, sorry, I do not received this topic before.
>>
>> 2.
>> There some valid performance advantage over strpos()?
>>
>> 3.
>> And about the "market" for this new function?
>> I mean, about users really need a new function like it on core.
>>
>> 4.
>> And about the case sensitiblity?
>> Should have some function like stribegins() or will be an argument?
>>
>> In general, I like this implementation, but I like to know about you
>> in this questions.
>> I don't know the policy about implements new functions on "str namespace".
>>
>> Thanks!
>>
>> 2016-07-26 15:41 GMT-03:00  :
>>
>>> Hello,
>>>
>>> I would like to submit an RFC for adding a str_begins and str_ends
>>> function,
>>> in relation to https://bugs.php.net/bug.php?id=67035 and
>>> https://bugs.php.net/bug.php?id=50434. I've added those functions on my
>>> local PHP copy. I would like to make an RFC and a PR for adding it to the
>>> core PHP copy.
>>>
>>> Thanks,
>>>
>>> Will
>>>
>>> --
>>> 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] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

Looks good to me, go for it :)

Thanks,

- Davey

On Mon, Jul 25, 2016 at 2:14 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> Hi Davey,
>
> On Mon, Jul 25, 2016 at 5:46 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> >
> > On Mon, Jul 25, 2016 at 4:09 PM, Davey Shafik <da...@php.net> wrote:
> >> My suggestion:
> >>
> >> Re-start the vote, three options:
> >>
> >> Yes, new defaults (BC Break), Yes, old defaults (no BC break), No
> >>
> >> OR:
> >>
> >> add a second vote to the page, with:
> >>
> >> Use new defaults (BC Break), Use Old Defaults (No BC Break)
> >
> > Sounds good to me.
> > I'll use 2nd option and restart.
>
> I've updated the RFC.
> https://wiki.php.net/rfc/session-id-without-hashing
> I've set new vote end date to 2016/08/02 23:59:59.
>
> Could you check if the RFC is OK? If it's OK, I'll create a new thread
> for vote notice.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] Bundled SQLlite3

[Davey Shafik]

I'd like to see an updated SQLite in 7.1, this is part of shoring up the
stability of the release IMO.

- Davey

On Sun, Jul 24, 2016 at 11:57 PM, Anatol Belski 
wrote:

> Hi Christoph,
>
> > -Original Message-
> > From: Christoph Becker [mailto:cmbecke...@gmx.de]
> > Sent: Monday, July 25, 2016 12:49 AM
> > To: internals@lists.php.net
> > Subject: [PHP-DEV] Bundled SQLlite3
> >
> > Hi!
> >
> > What's our stance on updating the bundled SQLite3?
> >
> > Currently the PHP-5.6 and 7.0 branch have 3.8.10.2, while the PHP-7.1 and
> > master branch have 3.9.2 (sqlite3.h) respectively 3.13.0 (sqlite3.c).
> The latter
> > would have certainly to be fixed to be consistent, but I have some doubts
> > regarding sticking with old SQLite3 versions for supported PHP
> versions.  After all,
> > all minor versions at least as of SQLite 3.9.0 are "regularly scheduled
> > maintenance releases"[1], and it appears that no bug-fixes will be
> published for
> > non-current minor versions.
> >
> Normally it is ok to upgrade the bundled libsqlite. When done carefully,
> even in the stable branch. Fe from the news you've linked - "Yikes! The
> 3.12.0 and 3.12.1 releases contain a backwards compatibility bug!" :) But
> similar situations already happened before. However not upgrading it at all
> for 3 years is also not good, so fine with upgrading it from time to time.
> A respective RM should be better asked for approval.
>
> Regards
>
> Anatol
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

My suggestion:

Re-start the vote, three options:

Yes, new defaults (BC Break), Yes, old defaults (no BC break), No

OR:

add a second vote to the page, with:

Use new defaults (BC Break), Use Old Defaults (No BC Break)

On Sun, Jul 24, 2016 at 6:52 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> I would like to ask the default session ID string preference.
>
> Details of guessing an active session ID is described in previous mail.
> Please refer it for details.
>
> On Sun, Jul 24, 2016 at 4:57 PM, Yasuo Ohgaki  wrote:
> > I don't mind pausing vote to have consensus on how many bits for
> > session ID string is preferred.
>
> Current default is 128 bits with 32 chars. (Hex string which has 4
> bits per char)
> Pros: Compatible with current default.
> Cons: Weaker than proposed default
>
> Proposed default is 240 bits with 48 chars. (Special form which has 5
> bits per char)
> Pros: Stronger than current default.
> Cons: Incompatible with current default.
>
> 128 bits would be strong enough with CSPRNG, while 240 bits would be
> preferred as precaution.
> Which default would you prefer?
>
> I would like to restart vote based on the result.
>
> Thank you!
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

Just wanted to let you know I voted no because of the BC breaking change to
the INI options that could easily break many custom session handlers — any
session handler that stores the sessions in a fixed-width column will be
broken.

I'm fine changing the defaults in the php.ini-*, but not changing the
defaults in the code. Also, documenting the better values as recommended.

Putting my RM hat on, I'm not comfortable merging this in 7.1 with an
unnecessary BC breaking change. Changing the default is the BC break,
regardless of the _ability_ to change the settings back to the previous
values.



On Sat, Jul 23, 2016 at 9:50 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> Due to a defect in the RFC, vote is reopened for a week. Removed lines
> are indicated by . No additional lines nor modifications
> other than removed lines for session.use_strict_mode change.
> Sorry for the confusion!
>
> 
>
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> 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] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

Done, I guess it just needed a unique name, removing the first one kept the
new one only :)

- Davey

On Sat, Jul 23, 2016 at 10:50 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> Hi Davey,
>
> On Sun, Jul 24, 2016 at 2:37 PM, Davey Shafik <da...@php.net> wrote:
> >
> > It didn't actually reopen, and just setting closed to false, it kept the
> > original votes. So I added a second vote below. Bonus: the original is
> also
> > preserved.
> >
> > Hope that's OK.
>
> Oops, I thought flip-flopped the switch. Thanks you but wouldn't it
> easier with single vote entry?
> If you don't mind, I would like to have single vote section because
> this is reopen for a RFC defect.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Re: [PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

[Davey Shafik]

Yasuo,

It didn't actually reopen, and just setting closed to false, it kept the
original votes. So I added a second vote below. Bonus: the original is also
preserved.

Hope that's OK.

- Davey

On Sat, Jul 23, 2016 at 9:50 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> Due to a defect in the RFC, vote is reopened for a week. Removed lines
> are indicated by . No additional lines nor modifications
> other than removed lines for session.use_strict_mode change.
> Sorry for the confusion!
>
> 
>
> Currently session module uses obsolete MD5 for session ID. With
> CSPRNG, hashing is redundant and needless. It adds hash module
> dependency and inefficient (There is no reason to use hash for CSPRNG
> generated bytes).
>
> This proposal cleans up session code by removing hash.
>
> https://wiki.php.net/rfc/session-id-without-hashing
>
> I set vote requires 2/3 support.
> Please describe the reason why when you against this RFC. Reasons are
> important for improvements!
>
> 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: [RFC][VOTE] Session ID without hashing

[Davey Shafik]

Stas,

The issue is that changes were made once the voting started, and some of us
were waiting for the vote to restart:

> I'd like to see the vote re-run (1 week?) with the changes in place. I
didn't vote because I expected it to be restarted. I would have voted -1 on
the current proposal.

Changing the RFC during voting requires a _restart_ not an extension. The
vote must be re-run. I will not put this in 7.1 without a new vote.

- Davey

On Sat, Jul 23, 2016 at 12:50 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > We already had a vote, at it was completed. Having another vote on the
> > same subject, slightly modified, is highly irregular and contrary to
> > voting RFC, which mandates 6 month period or *substantial* changes (with
> > assumed new discussion period I imagine, since past discussion can't
> > really count for substantially changed proposal) to schedule a new vote
> > on a rejected proposal.
> >
> > This also gives pretty bad example - on failed vote, tweak a little
> > issue and issue immediate revote, repeat until one of the votes
> > succeeds. I understand that this is not at all your intent here, but
> > it's the pattern that we do not want to enable.
> >
> > I voted yes for it, and it is a pity that it failed, as it seems,
> > because of a miscommunication (maybe not, I don't know), but going
> > against our own agreed process I think is not a good outcome either.
>
> Oops, I thought I was talking about another RFC vote that failed. Sorry
> for the confusion. This one seems to have succeeded. This is weirder
> case then... I'd say just implement the uncontroversial part then and
> submit the controversial part as a new RFC?
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] PHP 5.5.38 is released

[Davey Shafik]

Thank you Julien and David for your hard work and a job well done!

Congrats! :)

- Davey

On Fri, Jul 22, 2016 at 8:01 AM, Julien Pauli  wrote:

> Hi.
>
> The PHP development team announces the immediate availability of PHP
> 5.5.38.
> Several security related issues were fixed in this release. All
> PHP 5.5 users are encouraged to upgrade to this version.
>
> Note that this should be the last PHP-5.5 release, which now reaches
> its end of life. All PHP 5.5 users are encouraged to start a migration
> to PHP 5.6 or PHP 7.0
>
> For source downloads of PHP 5.5.38 please visit our downloads page:
> http://www.php.net/downloads.php
>
>  Windows binaries can be found on http://windows.php.net/download/.
>
> The list of changes is recorded in the ChangeLog:
> http://www.php.net/ChangeLog-5.php#5.5.38
>
> To verify the downloads, you can use the following information:
>
> php-5.5.38.tar.bz2
> SHA256 hash:
> 473c81ebb2e48ca468caee031762266651843d7227c18a824add9b07b9393e38
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJXkimxAAoJEP6FfZqQ2Q7B7sYH/iPkuJTjJyLgd6Wutg+kSnxH
> L48+owpKOwSk01FgAGsJcVekLwPohWFUAhTuvqu8rDDhwZONRgBYx4mW1vFD+M+g
> 1gsAfHMdjOXGmE2w2xCg/pYSqcxuARoqrztegJ5neuUsYOMlLfX9PPmJPbMHKdYO
> ALYjP0TttMc9B7m5vs7WipHBsbK5d+oE322Ei3RtQg/JLyaIzgKIhi36urAtDzIJ
> xnAuqWC852qaA0t8oApjDSsbf16Nqz+yILyoJRTYBj//9+IzaGOMGd4BhhNlXmzg
> KpZRxw/hUNJqdfYDxizr3y0nmcbNwTwDtuU95OLUUaO8c8wfNICYWOsEXbRpbw4=
> =6+l9
> -END PGP SIGNATURE-
>
> php-5.5.38.tar.gz
> SHA256 hash:
> 4f458c9b504269615715a62f182b7c2f89bb8284f484befc221b56a1571b506e
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJXkimeAAoJEP6FfZqQ2Q7BYlUH/RPuKu37xnkypydJLiQfEtE0
> odQ5Eh876sjdLQkMbv52+SXbEf2HTMokBcDcJKYDodcWHDusUE97aUVgmSdWMPzG
> CU6Ycf4v0/hRL6zzMr1a7OHltPtEQ/UIHtPlI3u33fYMU7N0qvUVd2oQvZfMVxKd
> BjuQX9CfI0tQem/JlramDWvA3BlT2gXfeaQ9UlcQqKoSUszzMVFRekR8sx6lBJWW
> UjwNdR4guUgjUBuZprgZUNfRu5XYf53ZiKRa9Fzb4qgD+nvOFeeAE2Oi8Ipf39Ni
> XWC3tfhUhvuiGL7+4lr/5DY5bNMSc/EV40XwfunmB+cJSd6ugnClvcvfW5iFRPc=
> =I3aY
> -END PGP SIGNATURE-
>
> php-5.5.38.tar.xz
> SHA256 hash:
> cb527c44b48343c8557fe2446464ff1d4695155a95601083e5d1f175df95580f
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJXkimsAAoJEP6FfZqQ2Q7BXgkH/0i13tKhSKfTLY+a3tGfUIJ2
> A61pOGtTNS3+ApzZiaqA+g74d8N4Fu75AmHQrha1HJqATMb3UJp3F09V9YP9XGDj
> oSX6nU59o+lTjMneXWLGvQIm98+8Zn4GqEWW6/Q+d04Hoilc+xl1W7EDsOyXJ34C
> Qv6gtCBG2uFn6e2sjt3hwmrOAO+Jb2oJ1X3NVobhbvv+uy1t6sEOUTntA4dqlQbz
> Gct5D7nI5yFEfgEtYIVI71yVzegIHBXqArxZdj92YLwEvhRCA4pONTKbjvTE7UmF
> rFIuT+wefOpq+JaIu+fr/OwpkX5Y2TDAPNPvziMOKRCbHhxX0og4mGizTnnIJps=
> =kv7Q
> -END PGP SIGNATURE-
>
> Julien Pauli & David Soria Parra
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] Re: PHP 7.1.0beta1 Released

[Davey Shafik]

Downloads are actually at https://downloads.php.net/~ab/

And Thanks to Anatol for his assist with this release and for pushing these
up.

- Davey

On Thu, Jul 21, 2016 at 2:37 AM, Davey Shafik <m...@daveyshafik.com> wrote:

> Hi,
>
> The first beta for 7.1.0 was just released. With this release we are now
> in feature freeze for 7.1.
>
> Any further additions to 7.1 moving forward must be approved by the
> release managers (Joe Watkins, or myself).
>
> The release can be downloaded from:
>
> https://downloads.php.net/~krakjoe/
>
> The Windows binaries will be available at the following URL shortly (they
> need to be rebuilt following a re-tag with updated NEWS only):
>
> http://windows.php.net/qa/
>
> Please test it carefully, and report any bugs in the bug system.
>
> The next release will be tagged on Tuesday August 6th and released on
> Thursday August 8th.
>
> Thanks,
>
>  Davey Shafik & Joe Watkins
>  PHP 7.1 Release Managers
>
> php-7.1.0beta1.tar.bz2
> SHA256 hash:
> 14b29e5a2cb13c071a7d70784ad3f43230cba09e4bda6d90c3c1dfaa070ac882
> MD5 hash: 68fbd1bc98ba7c636dabc85698bc0046
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJXkJLAAAoJEGWqzKLMO04mZq4IAIR0dEfKdn5wcx+lg5h8FC+k
> 5U+x0MtP+i384ZB7oMQnzFcSZcwF+cHfNsBH+LFnns4qww8+tdza8XjL/xddsgAi
> 6FPvqlyrZMRzoynh+/vF2QJeQJlwiGqNmULJkfIz3FRhV8jTMN8+HJ146mnoGUy3
> 3gCtCUcSeGGdgUbg6v/TJVmiD5HC+Ef3S1klj8XVn27CDBhaaUbNlcS8astgqmpA
> UdxjZxjVNcS1HLW1VQk6DhsjOxVgPoQBp3V5rb1Cvt/Qt43FcqjacT/k+t+XyN7F
> uarFHGOEbujoaooO4tXXZsYb0BcPtvWBfxiS6jL6mxLFJqOe4ACQCUAR6dHZw8w=
> =Vrk3
> -END PGP SIGNATURE-
>
>
> php-7.1.0beta1.tar.gz
> SHA256 hash:
> 2f27caf12ea8b3fc2322bc12c8e4863c3fd8055e19c3f18d5c204b90754513d4
> MD5 hash: 027419ebe7b5a9b5433ced25a9594061
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJXkJLKAAoJEGWqzKLMO04mMR0H/A2J2wUDU63YpWYeQDLdUIeK
> JsVKWueptEM/7E2ddvyaZwLEIT2ZQhF8DarCaDPbgZ9sVwDDt0lcd8CTOKnO2YTA
> zbI8ZiQYx9xfXaoxjWETancM2mKuBuEzaJkU25QGe0eJzUnlwE268WsU32tnxgy7
> RBrCFoAamLPT/o7/mfY2M5r4ZXPX7/AJAUsKsNOG6jsZJ/2CTPBBfTndlpI8MFpk
> Tdnmo6VTnlbaQ/8lbHDV58p4PwdYPiv3vnA7Nc7c9IoJtAgpN7l8wm1vXpaU3RxF
> 8rMOUYFYfggmuOlzGUmhje5TGZqhheL1TFFKMnxnygs5kpshFF+Kxh+gbgkpBxY=
> =z+UW
> -END PGP SIGNATURE-
>
>
> php-7.1.0beta1.tar.xz
> SHA256 hash:
> e49a4e6c1bbda42a4571433fd3db7ad424213dbe4ac0d9148c58d7e38d2870e5
> MD5 hash: f63c3acc5c15e69853a164b40e107d7f
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAABAgAGBQJXkJLLAAoJEGWqzKLMO04ms+oIAJonC3vB1Rrm9EqFPYbj60uD
> NDfta6D+3zqQVpX1LW7scIKOPwI41/96jvCnpizMDSD1ZmNZgbF9/ud8Q4T9kXmK
> BIOS75gVTTbziiVWKmDoGBHwvgIys0Il6NRKj6+BAJOb4064RoKPvfBcHSaBv+9h
> NSZnM8sWO4nHM6rJX+bsYcNh0HBYcneseuq0/OcTVDDMIO6zH+trRKnSJbX60oMG
> tSTTuj/+EPzmgg9bqMotaadULTV2ecCycdWABdu4OOua3dBKT/nQG4H7Q2WejHeP
> 0z99EXc6OXqTVOr/MAtxWOU57JWp960PoJcvjNsSV2rwFLQvPXlLuwgHbCf4rg0=
> =54kD
> -END PGP SIGNATURE-
>

[PHP-DEV] PHP 7.1.0beta1 Released

[Davey Shafik]

Hi,

The first beta for 7.1.0 was just released. With this release we are now in
feature freeze for 7.1.

Any further additions to 7.1 moving forward must be approved by the release
managers (Joe Watkins, or myself).

The release can be downloaded from:

https://downloads.php.net/~krakjoe/

The Windows binaries will be available at the following URL shortly (they
need to be rebuilt following a re-tag with updated NEWS only):

http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.

The next release will be tagged on Tuesday August 6th and released on
Thursday August 8th.

Thanks,

 Davey Shafik & Joe Watkins
 PHP 7.1 Release Managers

php-7.1.0beta1.tar.bz2
SHA256 hash:
14b29e5a2cb13c071a7d70784ad3f43230cba09e4bda6d90c3c1dfaa070ac882
MD5 hash: 68fbd1bc98ba7c636dabc85698bc0046
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXkJLAAAoJEGWqzKLMO04mZq4IAIR0dEfKdn5wcx+lg5h8FC+k
5U+x0MtP+i384ZB7oMQnzFcSZcwF+cHfNsBH+LFnns4qww8+tdza8XjL/xddsgAi
6FPvqlyrZMRzoynh+/vF2QJeQJlwiGqNmULJkfIz3FRhV8jTMN8+HJ146mnoGUy3
3gCtCUcSeGGdgUbg6v/TJVmiD5HC+Ef3S1klj8XVn27CDBhaaUbNlcS8astgqmpA
UdxjZxjVNcS1HLW1VQk6DhsjOxVgPoQBp3V5rb1Cvt/Qt43FcqjacT/k+t+XyN7F
uarFHGOEbujoaooO4tXXZsYb0BcPtvWBfxiS6jL6mxLFJqOe4ACQCUAR6dHZw8w=
=Vrk3
-END PGP SIGNATURE-


php-7.1.0beta1.tar.gz
SHA256 hash:
2f27caf12ea8b3fc2322bc12c8e4863c3fd8055e19c3f18d5c204b90754513d4
MD5 hash: 027419ebe7b5a9b5433ced25a9594061
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXkJLKAAoJEGWqzKLMO04mMR0H/A2J2wUDU63YpWYeQDLdUIeK
JsVKWueptEM/7E2ddvyaZwLEIT2ZQhF8DarCaDPbgZ9sVwDDt0lcd8CTOKnO2YTA
zbI8ZiQYx9xfXaoxjWETancM2mKuBuEzaJkU25QGe0eJzUnlwE268WsU32tnxgy7
RBrCFoAamLPT/o7/mfY2M5r4ZXPX7/AJAUsKsNOG6jsZJ/2CTPBBfTndlpI8MFpk
Tdnmo6VTnlbaQ/8lbHDV58p4PwdYPiv3vnA7Nc7c9IoJtAgpN7l8wm1vXpaU3RxF
8rMOUYFYfggmuOlzGUmhje5TGZqhheL1TFFKMnxnygs5kpshFF+Kxh+gbgkpBxY=
=z+UW
-END PGP SIGNATURE-


php-7.1.0beta1.tar.xz
SHA256 hash:
e49a4e6c1bbda42a4571433fd3db7ad424213dbe4ac0d9148c58d7e38d2870e5
MD5 hash: f63c3acc5c15e69853a164b40e107d7f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXkJLLAAoJEGWqzKLMO04ms+oIAJonC3vB1Rrm9EqFPYbj60uD
NDfta6D+3zqQVpX1LW7scIKOPwI41/96jvCnpizMDSD1ZmNZgbF9/ud8Q4T9kXmK
BIOS75gVTTbziiVWKmDoGBHwvgIys0Il6NRKj6+BAJOb4064RoKPvfBcHSaBv+9h
NSZnM8sWO4nHM6rJX+bsYcNh0HBYcneseuq0/OcTVDDMIO6zH+trRKnSJbX60oMG
tSTTuj/+EPzmgg9bqMotaadULTV2ecCycdWABdu4OOua3dBKT/nQG4H7Q2WejHeP
0z99EXc6OXqTVOr/MAtxWOU57JWp960PoJcvjNsSV2rwFLQvPXlLuwgHbCf4rg0=
=54kD
-END PGP SIGNATURE-

[PHP-DEV] PHP-7.1 Branched

[Davey Shafik]

Hey folks,

as mentioned in the last release email, the PHP-7.1 branch has now been
created.

I will be creating the PHP 7.1.0beta1 release off it in the next few
minutes.

However, this effectively means that master is open for PHP 7.2 (or 8.0 :P)
and any further commits specifically for 7.1 must land in the PHP-7.1
branch.

Thanks,

- Davey