Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Theodore Brown]

On Wed, Aug 28, 2019 at 4:33 AM Nikita Popov  wrote:

> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
> notice is really quite mind-boggling.
>
> I've prepared an RFC with some suggested classifications, though there's
> room for bikeshedding here...
>
> https://wiki.php.net/rfc/engine_warnings

Nikita,

Thank you for your effort in putting together this RFC and explaining
the rationale for each change. From my perspective, converting more
error conditions from a notice/warning to an exception as proposed
will be a welcome step forward for the language.

I've frequently used PHP to write one-time scripts for migrating data
between services, or scripting changes to thousands of items via an
API. The lack of exceptions for things like undefined variables and
using a scalar value as an array has bitten me on multiple occasions.

There have even been times when simple mistakes like a typo in a
variable name have led to data loss, since instead of causing the
script to halt it just output a notice and continued running with
bad data.

In my experience, PHP's historical lax treatment of errors, far from
making it faster and easier to write scripts, *actually makes it take
longer* since I have to add extra assertions and boilerplate custom
error handling code in order to ensure that scripts don't keep
running in a broken state when one of these errors occurs.

So in summary, I think the proposed RFC is a solid step forward which
will help prevent expensive mistakes and make it simpler to write
robust code.

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

[PHP-DEV] PHP 7.2.22 Released

[Sara Golemon]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.22. This is a security release which also contains several minor bug
fixes.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.22 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: http://php.net/releases/7_2_22.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.22


Many thanks to all the contributors and supporters!


Sara Golemon, Remi Collet

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Stanislav Malyshev]

Hi!

>> encountered a PHP developer who thought using uninitialized variables
>> was fine.
> 
> Now you have. Nice to meet you.

And there are more of us. You learn something new every day!

>> I knew it worked, but I always considered this to basically be
>> the PHP equivalent of undefined behavior in C. And I don't think anyone

It's not. It's very well defined behavior, that is not going to break -
unless it is broken intentionally in a zeal for adding more strictness
for the sake of strictness. So, another thing to learn. I love learning
new things, and love helping others do so!

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

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Christian Schneider]

Am 29.08.2019 um 18:25 schrieb Aegir Leet :
> Before reading the responses to this thread, I had honestly never
> encountered a PHP developer who thought using uninitialized variables
> was fine.

Now you have. Nice to meet you.

> I knew it worked, but I always considered this to basically be
> the PHP equivalent of undefined behavior in C. And I don't think anyone
> would get mad if a new GCC version broke the way they were abusing UB.

That's where you are mixing things up: It is well-defined behaviour, even if 
you personally don't like it.

A better analogy is static variables in C. It is common (and not considered 
bad) practice to not explicitly set a variable to 0 as that is the default 
value.

Example: 
https://github.com/git/git/blob/6d5b26420848ec3bc7eae46a7ffa54f20276249d/delta-islands.c#L26

- Chris


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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Claude Pache]

> Le 29 août 2019 à 18:25, Aegir Leet  a écrit :
> 
> Either way, if you want a less strict language, that language already
> exists: It's the current version of PHP and you and everyone else who
> likes the way it works can keep using it.
> Meanwhile, I think most people currently doing serious PHP work would
> *love* some more strictness and I don't think keeping your old code
> running on a brand new version of the language is a good enough reason
> to keep this feature out of 8.0.


Strictness is undoubtedly a good thing — as a tool, not as a dogma. But BC 
break is not necessary for more strictness. As of today, you can write a custom 
error-handler that converts all non-handled warnings into program crashes 
(after having sent a fiery bug report to the developer).

—Claude

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Claude Pache]

> Le 29 août 2019 à 18:13, Matthew Brown  a écrit :
> 
> I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used 
> today mostly as its architect intended at its founding. PHP, having 
> transitioned from a templating system to a fully-fledged language, is used 
> quite differently.


Today, PHP is a fully-fledged language *and* a templating system.

—Claude

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Todd Ruth]

> From: Aegir Leet 
> Either way, if you want a less strict language, that language already
> exists: It's the current version of PHP and you and everyone else who
> likes the way it works can keep using it.

For approximately 3 years.  Please remember "end of life".  We'd still be using 
php5 today if it weren't for "end of life".  I interpret the above paragraph as 
a request to split between p++ and php classic.  I'd be fine with that and use 
php classic, but I believe the idea of splitting failed by a very wide margin.

- Todd

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Aegir Leet]

Before reading the responses to this thread, I had honestly never
encountered a PHP developer who thought using uninitialized variables
was fine. I knew it worked, but I always considered this to basically be
the PHP equivalent of undefined behavior in C. And I don't think anyone
would get mad if a new GCC version broke the way they were abusing UB.

To me and to every developer I've ever known, the only difference
between a notice and a warning is the severity of the error. But they're
both considered errors - mistakes you made in your code that you need to
fix. I'm fairly certain this is how most developers treat them in the
real world.

Either way, if you want a less strict language, that language already
exists: It's the current version of PHP and you and everyone else who
likes the way it works can keep using it.
Meanwhile, I think most people currently doing serious PHP work would
*love* some more strictness and I don't think keeping your old code
running on a brand new version of the language is a good enough reason
to keep this feature out of 8.0. What's the point of even having major
releases if every potential BC break gets shot down by the same 3 people
on this mailing list?

As for the check engine light analogy, I guess instead of saying "this
is fine", you just smash your entire dashboard with a hammer to make the
problem go away. Because that's what using @ or error_reporting does.

I hope this RFC passes, but I don't see any point in discussing it
further here, so I'll go back to lurking now.

On 29.08.2019 16:22, Zeev Suraski wrote:
>
>
> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals
> mailto:internals@lists.php.net>> wrote:
>
> I know what the manual says about notices. But I don't agree with
> interpreting "could happen in the normal course of running a
> script" as "it's perfectly fine if this part of your code triggers
> a notice consistently and every time it goes down this particular
> code path". Rather, I've always interpreted this as "under
> certain, rare, unforeseen circumstances, your code could generate
> a notice here, probably because of something that is outside of
> your control".
>
> That's how I've always treated them at least.
>
>
> And that's entirely within your right to do so - but what the manual
> says is accurate.  Calling me delusional in my interpretation of it is
> somewhat awkward (to put it mildly), I have a pretty good idea of why
> we added the different error levels - I wrote much of it myself.
>
> The whole point of having notices as something that's separate from
> warnings is that they have different semantics, and that semantics is
> captured very accurately in the manual.  They are used to mark issues
> which may be problems, but may also be perfectly fine (unlike
> warnings, which generally speaking mean that something bad happened,
> but not bad enough to halt execution).  Notices were meant to help you
> implement a more strict style of coding, and they may help you catch
> certain types of bugs, but you can have perfectly working, bug-free
> code that generates notices.
>
> Regardless of the exact semantics, don't you think a program that
> generates a constant stream of notices is a bit strange? That
> sounds like something everyone would naturally want to avoid. You
> don't drive your car with the check engine light permanently on
> and say "this is fine", right?
>
>
> Except you can purposely turn off this 'check engine' light, never to
> see it again if you choose to.  And that it's really not at all
> similar to 'check engine', but a lot closer to 'check cleaning fluid',
> or even 'clean windshield' (if cars had a dashboard light for that). 
> Even that is not a good analogy - as folks often actually purposely
> write code that generates notices (which would be purposely hidden,
> either by error_reporting setting or using @) that is 100% bug-free
> and working as intended.  So no, there's nothing strange about it if
> you buy into that approach.  If you don't (and I know you don't) -
> that's absolutely fine - it's up to you.
>
> Zeev
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used 
today mostly as its architect intended at its founding. PHP, having 
transitioned from a templating system to a fully-fledged language, is used 
quite differently.

> On Aug 29, 2019, at 11:50 AM, Chase Peeler  wrote:
> 
>> On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski  wrote:
>> 
>> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
>> internals@lists.php.net> wrote:
>> 
>>> I know what the manual says about notices. But I don't agree with
>>> interpreting "could happen in the normal course of running a script" as
>>> "it's perfectly fine if this part of your code triggers a notice
>>> consistently and every time it goes down this particular code path".
>>> Rather, I've always interpreted this as "under certain, rare, unforeseen
>>> circumstances, your code could generate a notice here, probably because
>> of
>>> something that is outside of your control".
>>> 
>>> That's how I've always treated them at least.
>>> 
>> 
>> And that's entirely within your right to do so - but what the manual says
>> is accurate.  Calling me delusional in my interpretation of it is somewhat
>> awkward (to put it mildly), I have a pretty good idea of why we added the
>> different error levels - I wrote much of it myself.
>> 
>> The whole point of having notices as something that's separate from
>> warnings is that they have different semantics, and that semantics is
>> captured very accurately in the manual.  They are used to mark issues which
>> may be problems, but may also be perfectly fine (unlike warnings, which
>> generally speaking mean that something bad happened, but not bad enough to
>> halt execution).  Notices were meant to help you implement a more strict
>> style of coding, and they may help you catch certain types of bugs, but you
>> can have perfectly working, bug-free code that generates notices.
>> 
>> Regardless of the exact semantics, don't you think a program that generates
>>> a constant stream of notices is a bit strange? That sounds like something
>>> everyone would naturally want to avoid. You don't drive your car with the
>>> check engine light permanently on and say "this is fine", right?
>> 
>> 
>> Except you can purposely turn off this 'check engine' light, never to see
>> it again if you choose to.  And that it's really not at all similar to
>> 'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
>> windshield' (if cars had a dashboard light for that).  Even that is not a
>> good analogy - as folks often actually purposely write code that generates
>> notices (which would be purposely hidden, either by error_reporting setting
>> or using @) that is 100% bug-free and working as intended.  So no, there's
>> nothing strange about it if you buy into that approach.  If you don't (and
>> I know you don't) - that's absolutely fine - it's up to you.
>> 
>> Zeev
>> 
> I just wanted to bring up a few other points. First, as I think Stanislav
> has done a good job of pointing out, the flexibility of PHP is one of its
> greatest features. The nice thing about a flexible and forgiving language
> is that you can always put additional things in place on top of it to make
> it more strict and rigid if you want. Once you force a language to be
> strict and rigid, however, it's much harder, if not impossible, to add back
> in flexibility.
> 
> A lot of my emails on this thread have been focused on the burden to
> developers caused by the BC break. While I still think that is an important
> consideration, it distracted me from my initial view which was we shouldn't
> do this because it's just a bad idea. I understand all of the arguments for
> enforcing variable initialization. I agree with most of them as well.
> However, I think there are a myriad of ways that individuals and teams can
> do that enforcement without forcing it on every single developer whether
> they want it or not.
> 
> A lot of comparisons have been made to other languages. I do a lot of work
> with javascript and I have a good amount of experience with c# as well.
> I've used many other languages at times (c, c++, java, perl, ruby, etc.) as
> well. In c#, you don't have to initialize your variables - you have to
> declare them. Some types, like ints, are automatically initialized to 0
> unless explicitly initialized to something else. PHP doesn't require you to
> declare variables. So, while c# might require "int i; i++;" you can achieve
> the same thing in PHP with "$i++;" - neither one requires an explicit
> initialization.
> 
> A few people have referred to the fact that I have instances of undeclared
> variables as technical debt. As I said earlier, I've engaged in these
> discussions because I don't think just calling something technical debt
> should be justification for a change. The fact that a large number of
> developers might have technical debt in a certain area should be considered
> when weighing the pros and cons of a breaki

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski  wrote:

> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
> internals@lists.php.net> wrote:
>
> > I know what the manual says about notices. But I don't agree with
> > interpreting "could happen in the normal course of running a script" as
> > "it's perfectly fine if this part of your code triggers a notice
> > consistently and every time it goes down this particular code path".
> > Rather, I've always interpreted this as "under certain, rare, unforeseen
> > circumstances, your code could generate a notice here, probably because
> of
> > something that is outside of your control".
> >
> > That's how I've always treated them at least.
> >
>
> And that's entirely within your right to do so - but what the manual says
> is accurate.  Calling me delusional in my interpretation of it is somewhat
> awkward (to put it mildly), I have a pretty good idea of why we added the
> different error levels - I wrote much of it myself.
>
> The whole point of having notices as something that's separate from
> warnings is that they have different semantics, and that semantics is
> captured very accurately in the manual.  They are used to mark issues which
> may be problems, but may also be perfectly fine (unlike warnings, which
> generally speaking mean that something bad happened, but not bad enough to
> halt execution).  Notices were meant to help you implement a more strict
> style of coding, and they may help you catch certain types of bugs, but you
> can have perfectly working, bug-free code that generates notices.
>
> Regardless of the exact semantics, don't you think a program that generates
> > a constant stream of notices is a bit strange? That sounds like something
> > everyone would naturally want to avoid. You don't drive your car with the
> > check engine light permanently on and say "this is fine", right?
>
>
> Except you can purposely turn off this 'check engine' light, never to see
> it again if you choose to.  And that it's really not at all similar to
> 'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
> windshield' (if cars had a dashboard light for that).  Even that is not a
> good analogy - as folks often actually purposely write code that generates
> notices (which would be purposely hidden, either by error_reporting setting
> or using @) that is 100% bug-free and working as intended.  So no, there's
> nothing strange about it if you buy into that approach.  If you don't (and
> I know you don't) - that's absolutely fine - it's up to you.
>
> Zeev
>
I just wanted to bring up a few other points. First, as I think Stanislav
has done a good job of pointing out, the flexibility of PHP is one of its
greatest features. The nice thing about a flexible and forgiving language
is that you can always put additional things in place on top of it to make
it more strict and rigid if you want. Once you force a language to be
strict and rigid, however, it's much harder, if not impossible, to add back
in flexibility.

A lot of my emails on this thread have been focused on the burden to
developers caused by the BC break. While I still think that is an important
consideration, it distracted me from my initial view which was we shouldn't
do this because it's just a bad idea. I understand all of the arguments for
enforcing variable initialization. I agree with most of them as well.
However, I think there are a myriad of ways that individuals and teams can
do that enforcement without forcing it on every single developer whether
they want it or not.

A lot of comparisons have been made to other languages. I do a lot of work
with javascript and I have a good amount of experience with c# as well.
I've used many other languages at times (c, c++, java, perl, ruby, etc.) as
well. In c#, you don't have to initialize your variables - you have to
declare them. Some types, like ints, are automatically initialized to 0
unless explicitly initialized to something else. PHP doesn't require you to
declare variables. So, while c# might require "int i; i++;" you can achieve
the same thing in PHP with "$i++;" - neither one requires an explicit
initialization.

A few people have referred to the fact that I have instances of undeclared
variables as technical debt. As I said earlier, I've engaged in these
discussions because I don't think just calling something technical debt
should be justification for a change. The fact that a large number of
developers might have technical debt in a certain area should be considered
when weighing the pros and cons of a breaking change. That being said, I do
NOT consider such code to be technical debt or bad code that needs to be
fixed. The only way it becomes either of those if with the implementation
of this RFC. It's a bit disingenuous to tell developers they have to make
large changes, and when they push back, tell them it's their fault for
accruing so much technical debt - when it's the RFC itself that actually
causes the techn

Re: [PHP-DEV] Reminder: Mailing list rules

[Zeev Suraski]

On Thu, Aug 29, 2019 at 3:48 PM Alexandru Pătrănescu 
wrote:

> Zeev, you might not agree with rules and hints but I strongly believe that
> they are great rules.
>

I think many of them are great (such as not posting when agitated, thinking
about what you want to say, being respectful, etc.), and some are not so
great (like asking people to combine responses into a single message - I
think it's extremely messy).  Others are good as guidelines, but not as
rules.


> We all have to respect everyone that might be involved in a thread.
> Replying often on the same thread does not let everyone involved reading
> and understanding what others are saying, including yourself.
> And IMHO that is a sign of disrespect, even if there is no real intention
> do it.
>

I completely disagree that it's in any way disrespectful.  Internals is the
electronic equivalent of a discussion panel, it always has been.
Artificially limiting the number of messages a person can send has no place
here, as long as they're on topic.  Sure, if the person finds themselves
saying the exact same thing again and again - then it's probably not very
productive (but still, not disrespectful in any way);  But more often than
not, it's about different aspects of the topic, or replies to different
feedback coming from different people over the source of the day - and
there's absolutely nothing wrong with the same person replying to many of
them.

We should always take time to think about you response, take time when
> writing the response and take time to read it again before sending it.
> IMHO, This shows that you care for the discussion and community.


I wholeheartedly agree.

Zeev

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Zeev Suraski]

On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
internals@lists.php.net> wrote:

> I know what the manual says about notices. But I don't agree with
> interpreting "could happen in the normal course of running a script" as
> "it's perfectly fine if this part of your code triggers a notice
> consistently and every time it goes down this particular code path".
> Rather, I've always interpreted this as "under certain, rare, unforeseen
> circumstances, your code could generate a notice here, probably because of
> something that is outside of your control".
>
> That's how I've always treated them at least.
>

And that's entirely within your right to do so - but what the manual says
is accurate.  Calling me delusional in my interpretation of it is somewhat
awkward (to put it mildly), I have a pretty good idea of why we added the
different error levels - I wrote much of it myself.

The whole point of having notices as something that's separate from
warnings is that they have different semantics, and that semantics is
captured very accurately in the manual.  They are used to mark issues which
may be problems, but may also be perfectly fine (unlike warnings, which
generally speaking mean that something bad happened, but not bad enough to
halt execution).  Notices were meant to help you implement a more strict
style of coding, and they may help you catch certain types of bugs, but you
can have perfectly working, bug-free code that generates notices.

Regardless of the exact semantics, don't you think a program that generates
> a constant stream of notices is a bit strange? That sounds like something
> everyone would naturally want to avoid. You don't drive your car with the
> check engine light permanently on and say "this is fine", right?


Except you can purposely turn off this 'check engine' light, never to see
it again if you choose to.  And that it's really not at all similar to
'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
windshield' (if cars had a dashboard light for that).  Even that is not a
good analogy - as folks often actually purposely write code that generates
notices (which would be purposely hidden, either by error_reporting setting
or using @) that is 100% bug-free and working as intended.  So no, there's
nothing strange about it if you buy into that approach.  If you don't (and
I know you don't) - that's absolutely fine - it's up to you.

Zeev

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Aegir Leet via internals]

I know what the manual says about notices. But I don't agree with interpreting 
"could happen in the normal course of running a script" as "it's perfectly fine 
if this part of your code triggers a notice consistently and every time it goes 
down this particular code path". Rather, I've always interpreted this as "under 
certain, rare, unforeseen circumstances, your code could generate a notice 
here, probably because of something that is outside of your control".

That's how I've always treated them at least.

Regardless of the exact semantics, don't you think a program that generates a 
constant stream of notices is a bit strange? That sounds like something 
everyone would naturally want to avoid. You don't drive your car with the check 
engine light permanently on and say "this is fine", right?

On 29.08.19 14:43, Claude Pache wrote:


Le 29 août 2019 à 13:33, Aegir Leet via internals 
mailto:internals@lists.php.net>> a écrit :

I'm sorry, but if you seriously believe doing something that generates a
notice (or warning, or error, ...) is not a bug - you're delusional.

No, what you think is not at all how notices were designed. From the manual 
(https://www.php.net/errorfunc.constants):

E_NOTICE  — Run-time notices. Indicate that the script encountered something 
that could indicate an error, but could also happen in the normal course of 
running a script.

One can discuss whether unitialised variables should trigger a notice or a 
warning. But let us respect the semantics of the language features.

—Claude

Re: [PHP-DEV] Reminder: Mailing list rules

[Alexandru Pătrănescu]

Hi,

True! Thanks for bringing this up, Nikita.
I wanted to mention the rules on the "Reclassifying engine warnings" thread
as well.

Zeev, you might not agree with rules and hints but I strongly believe that
they are great rules.
Not posting too many times, not posting when you are agitated and angry,
thinking about what you want to say for more than few seconds before
replying are all good things to think about in order to have a more
productive discussion on email.

We all have to respect everyone that might be involved in a thread.
Replying often on the same thread does not let everyone involved reading
and understanding what others are saying, including yourself.
And IMHO that is a sign of disrespect, even if there is no real intention
do it.

I've seen this issue everywhere, both in enterprise threads with too many
persons or public OSS threads. It is never productive and it usually brings
fights and sentiments in a discussion.
We should always take time to think about you response, take time when
writing the response and take time to read it again before sending it.
IMHO, This shows that you care for the discussion and community.

Regards,
Alex


On Thu, Aug 29, 2019 at 11:24 AM Zeev Suraski  wrote:

> On Thu, Aug 29, 2019 at 10:43 AM Nikita Popov 
> wrote:
>
> > Hi internals,
> >
> > A gentle reminder to everyone that this mailing list has rules,
> documented
> > at https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md.
> > In
> > particular:
> >
>
> And a gentle reminder that these are guidelines (even the document itself
> refers to them as "hints", right above the part that was quoted), rather
> than rules that must be obeyed.  Specifically, there were many discussions
> over the years about the "no top-posting" rule (which I'm personally fine
> with in most cases) as well as the requirement to merge multiple responses
> into one (which I'm absolutely not fine with, and think is completely
> counter-productive).  Limiting the number of posts to 2-3 also makes
> absolutely no sense during a discussion - although not necessarily
> responding to each and every email usually does make sense.
>
> Zeev
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Claude Pache]

> Le 29 août 2019 à 13:33, Aegir Leet via internals  a 
> écrit :
> 
> I'm sorry, but if you seriously believe doing something that generates a 
> notice (or warning, or error, ...) is not a bug - you're delusional.

No, what you think is not at all how notices were designed. From the manual 
(https://www.php.net/errorfunc.constants 
):

E_NOTICE  — Run-time notices. Indicate that the script encountered something 
that could indicate an error, but could also happen in the normal course of 
running a script.

One can discuss whether unitialised variables should trigger a notice or a 
warning. But let us respect the semantics of the language features.

—Claude

[PHP-DEV] PHP 7.3.9 Released

[Christoph M. Becker]

The PHP development team announces the immediate availability of PHP
7.3.9. This is a security release which also contains several bug fixes.

All PHP 7.3 users are encouraged to upgrade to this version.

For source downloads of PHP 7.3.9 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: 
Downloads:
Windows downloads:
Changelog:


Many thanks to all the contributors and supporters!


Stanislav Malyshev, Christoph M. Becker


php-7.3.9.tar.bz2
SHA256 hash:
a39c9709a8c9eb7ea8ac4933ef7a78b92f7e5735a405c8b8e42ee39541d963c4
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl1ltKkMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2qeIQAIz8mjF2seYTLFacby/ZW12fdj/8UxV/to/6k244
Sv/wrN7f91QqJ3vRnfNXyBVjB+pEDkcY34NltYGFGvKilOjVsoaXHWGqxH6RrBDG
+SZ8tJx1TaQvFqKzvsE08VhO32QYajha42SI4MNVUkIXclkFhBcjMkvoP9sHCjH/
UbvUDnmZ7v1lc6zNg7lvmr0rhajN3Bfbb+ZZ9YCU9V5WF01+UlKZ9ZyiKtTmvLGx
uZj8tGs6awZ+qoJbkLNgzbklFf2s6ub6swzzpnl7evjdygGwmdqyWmDauAdWxXHe
AOmq8iD74kWrHmd0OU8eEuTWrJ7RUTzUyW/5RVzo1aTsxphoG19hUSgUGWYLZhxq
wbw4uERTVMSNw0GVfY7ROvq0ZduHMLRRrirRDQn2+of3zWHGpExyUvnESOLMgElA
F//L9vaxJWnjUBQtkGdB6nxKOfKJsLLOZlyZlnGQ0ztZuAcIrWZGesJ4xh8VkfhW
HVadHVXkYkYXV1izVZjBjagh2kGQXxB4qeQmiOU07MnsOj73XfeuUC+wj9PL7BBt
cgJ+K1QrKXJ+y0ix7871NGi0REsZoOhNWjd7OxZLFFWhf9x5eQq/jYDyQHenwM2r
ZA8qTMSaxd3YKVKOOsof5oxBlxNLTIervMCwQT4ZjxpnSzbIns5HKzvZ9wZOAp8R
I4op
=IgR5
-END PGP SIGNATURE-


php-7.3.9.tar.gz
SHA256 hash:
5ecc1b1ad7228ed2e99a970c45358871644fcab1d9fd079a7b129326a7bde42d
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl1ltLIMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2z7EQAIPYCxdsqom8GhXI1z0dHmXI7S5niUra/iCwJA8a
pqIqFo8/3enoB3I3ONUNcTxiMAuB/b4vBlykaYRONG+3b4mmPRZzNy4XgKHNIXqu
nyJCs7AMhPz/TxYAGBGsqQfNg8nvEim7rjOXd5bGgcCA0hWPnxf3dMfjeNxP2uIx
O6HtWaidp1YZzdDM9F4OeRBTsZfJccnAQwtZ7oQRcdqTlZhfmP8KlYzYhzsrEdiB
wcFpVZ9ewhu9xHoBUOtkvcEj66VhDaYOuCw2f8TJKYUlKoCn+vTug2/zmsuF2Pru
CtnY2FwL7p3UsjXBwitvOLwZGavOIF8mOxcVhiFxHeTGW3iUBD2jufIkyxKGSjGF
52kj68NrA+gT9W2Xfddtwk/KfJC1HBrn1QeqfWXp/vcIG6v9ziM8uyYAE8QIoF4r
TbiRxuonq74M94cFJe2ALkACS4vW/6C6mkgBsMq5CQK+aCB7qpdrTjl4zdnp7AZ/
rtrSgDjqbnUCeGimrAEXdOFDM/87G3qdjGuhC2VAgrZeiXkfzwe2WBtMDG4bwwSp
hPNyjNX7qmjfYoip68C73iqec2xrSlo9F2c7bak44SQ0Ukxd8aBkwiZiBR+FcFJz
Cc4qqQPlrM3p6UiQXFbyQDj1YjHS8qiR+SYIqNLHE35whjCZuR48vcPjvdCjqcXd
nWAN
=bi3g
-END PGP SIGNATURE-


php-7.3.9.tar.xz
SHA256 hash:
4007f24a39822bef2805b75c625551d30be9eeed329d52eb0838fa5c1b91c1fd
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl1ltLIMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2Nq0P/RT1T1CgG1G7X8+NHegMi1EQW89HBDunoyHomSaO
E0jL6kzlu1Bu3xWQlmBdgY+032Qkyp0ouItjhQ/sVaMI6+vHd1KPEB8GGOUcpeGs
T7eF6Eg+XvItHX+xhyhkpJFkTX5vClQVTsQNYmOT2hbjuZ8LQO+rUu4ybf4TFanG
9tICrW/16O5hkNawAeHBz4qExWQnCNPwq5+q/fmSX8p9xSJ5P0lQIcsH1xr9w9hf
xtYNjFR2HIotPOIRm3Vce0j9Oceb1A0xLUxEwWiwxlUoE3uBKTZHlGgD9/v7SKEx
UwW87oxsltANeOEDZJdNcI7IQBaZpfKs52ySqvKj9Nsj2uYoP1de/ZPCoG5vc7z9
G7X5dPI8IaImi+iiyhgpv0GhtA0myQk7l7KoIjnxQhRjU47jBwG95TyctxporfNT
FaL3pCneWAJFLNclKW0H8kLx8gYip1uR6Vwn3P4xYweZm8i0vVxKpV5H98n6xAyL
sRE3hP+RgSxe5c+kToYomVXvdTO/o1V0OrhCZCrZ3XgfAJ85llm0DDsOIFuQTG+v
XAnxWqKILexoAMzYYLyT9nwf0AJUCwdWMyK3DDmW0DWD+y11Q8EPH/L1nwo84+om
iqb26SHNy87v4lEsLUsd/trkv4nMgVKGIeJLtIhzqTJcQbsBnhI4kjNZB1X6gtKy
oDFb
=96+G
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings

[Aegir Leet via internals]

I'm sorry, but if you seriously believe doing something that generates a 
notice (or warning, or error, ...) is not a bug - you're delusional. 
That is the very definition of a bug and notices/warnings/errors etc. 
are the mechanism the language uses to report these bugs to the 
developer. If doing X has been generating a notice for 20 years, then 
doing X is wrong and a bug, period. Why would there even be a notice if 
the language itself doesn't consider what you're doing to be buggy? What 
is the purpose of notices then? I really don't understand how anyone 
could contest this.

On 29.08.19 07:40, Zeev Suraski wrote:
>
> It's really awkward that anybody would be under the illusion that the way
> the language always behaved, consistently and well-documented pretty much
> from the its inception, is somehow a bug that everybody agrees on that's
> just waiting for someone to come over and fix it.

Re: [PHP-DEV] Reminder: Mailing list rules

[Zeev Suraski]

On Thu, Aug 29, 2019 at 10:43 AM Nikita Popov  wrote:

> Hi internals,
>
> A gentle reminder to everyone that this mailing list has rules, documented
> at https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md.
> In
> particular:
>

And a gentle reminder that these are guidelines (even the document itself
refers to them as "hints", right above the part that was quoted), rather
than rules that must be obeyed.  Specifically, there were many discussions
over the years about the "no top-posting" rule (which I'm personally fine
with in most cases) as well as the requirement to merge multiple responses
into one (which I'm absolutely not fine with, and think is completely
counter-productive).  Limiting the number of posts to 2-3 also makes
absolutely no sense during a discussion - although not necessarily
responding to each and every email usually does make sense.

Zeev

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Peter Bowyer]

On Thu, 29 Aug 2019 at 08:28, Christian Schneider 
wrote:

> Side-note: Which brings us back to the discussion about the downsides of
> language modes but as similar topics keep on popping up (although by the
> same people) you are slowly convincing me that going down that road is the
> best compromise.
>

Is there any technical reason PHP can't go the transpiler route? Let
everyone experiment with their own preferred changes, and pull the best
ideas, once proven, into core PHP?

Peter

[PHP-DEV] Reminder: Mailing list rules

[Nikita Popov]

Hi internals,

A gentle reminder to everyone that this mailing list has rules, documented
at https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md. In
particular:

> 1. If you notice that your posting ratio is much higher than that of
other people, double check the above rules. Try to wait a bit longer before
sending your replies to give other people more time to digest your answers
and more importantly give you the opportunity to make sure that you
aggregate your current position into a single mail instead of multiple ones.

Unless you are the author of an RFC, please limit yourself to sending no
more than 2 or 3 mails per thread per day -- if you send more, it is very
likely that you are either repeating yourself, or are performing a
mail-by-mail refutation, rather than aggregating your response.

Sending too many mails is very rude, because it drowns out discussions with
a single opinion, makes it hard for other people to be heard, and takes up
valuable time.

Thanks,
Nikita

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Christian Schneider]

Am 29.08.2019 um 08:22 schrieb Alexandru Pătrănescu :
> When you write code, in a "productive" way that you mention, it's perfectly
> fine if you write it for you and for now.
> 
> But most often, we write code for the future generations of developers that
> could be less skilled, for the future you that might have less context.
> Also, code will evolve in time and bugs will eventually apear. In my
> opinion and maybe you can agree, some of these bugs could be avoided if
> variable definition before reading would be enforced.

... and that's why Zeev suggests a strict mode for people who want it that way.

Side-note: Which brings us back to the discussion about the downsides of 
language modes but as similar topics keep on popping up (although by the same 
people) you are slowly convincing me that going down that road is the best 
compromise.

> For most of the developers and businesses using PHP, that is a trade they
> want to enforce but can't or does not know how to do it.

That "most developers" is highly subjective depending on who you ask.
And yes, you can easily turn undefined variables into exceptions right now 
(even globally), just use

set_error_handler(function($errno, $errstr) {
if (preg_match('/^Undefined variable/', $errstr))
throw new Exception($errstr);
return false;
}, E_NOTICE);

> I am for a default with more things enforced and maybe only allowed them
> based on declares, not the other way around.

Breaking code first and making migration harder instead of offering a clean 
migration path where developers opt-in to a new mode.

- Chris


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