Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[Mike Schinkel]

> On Mar 4, 2021, at 9:08 AM, G. P. B.  wrote:
> 
> Hello internals,
> 
> This new RFC which I'm proposing is to extend the capability of the error
> control operator @ to not just suppress diagnostic messages but also
> exceptions.
> It can currently be found on GitHub: [1]
> https://github.com/Girgias/error-control-operator-exceptions-rfc

Reading it several times, it is still not clear to me what the following means 
from the Proposal section:

-
Add the following syntax @ to suppress only the exceptions 
within the class list, this is similar to:

try
 {
expression
} 
catch (union_class_list) {}

As such @<\Throwable>expression and @expression are identical.
-

Specifically:

1. What @ means and what it would look like in practice, 
2. What catch(union_class_list) would look like in practice, 
3. What @<\Throwable>expression means and what it would look like in practice, 
and
4. Can you provide a few concrete code examples, please?


> The main motivation for this is to provide a path to migrate in a backwards
> compatible manner away from diagnostics such as E_WARNING to the use of
> exceptions without breaking 99% of PHP code which has been written in the
> last 25years.

I am not clear what you mean by "providing a path to migrate in a BC manner" 
here.  Would this require developers to prefix all functions calls with @ for 
functions changed in a future version of PHP to throw exceptions instead of 
returning values, assuming they do not have the green light from their 
stakeholders to make more substantive changes to their code?  

IOW, are you proposing a requirement to change existing code but in a form that 
could be (almost?) completely automated?  Is that the how you are envisioning 
this aspect of BC to work?

> This proposal on it's own would not be sufficient to trigger such a change
> for extensions but in combination with another proposal to introduce a
> `throw_on_error` declare [2] it could provide a bridge for a gradual
> transition to the use of more exceptions internally.

Would you also consider adding a reciprocal `error_on_exception` declare?

> Although I'm not thrilled with the idea of shoving more functionality into
> @ I don't see any other way, and thus I think it a necessary evil to
> improve the long term health of the PHP project.

What do you see as the downside of shoving more functionality into @?  Is the 
concern anything more than making the source for PHP more complicated to 
maintain?

> Feedback on this RFC and different ideas on how to tackle this topic are
> highly appreciated and welcomed.
> 
> Best regards,
> 
> George P. Banyard
> 
> [1] https://github.com/Girgias/error-control-operator-exceptions-rfc
> [2] Draft RFC for throw_on_error declare
> https://github.com/Girgias/php-rfc-throw-on-error-declare

-Mike

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

[PHP-DEV] PHP 8.0.3 Released

[Sara Golemon]

The PHP development team announces the immediate availability of PHP 8.0.3.
This is a bugfix release.

For source downloads of PHP 8.0.3 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/6ae23a005de4d399fe978e82e870c9f3

php-8.0.3.tar.gz
SHA256 hash:
e7ecfee901e0843377b64b2d8124132eae75bdb71a2675ba7c5c038d6592383d
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmA+a14QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcnhvD/0YZLdgLV6MhU7LShV3fJXku+jMkqnM2N5t
RL0eyYKGaN5GY0hdxIAkEdfKbbCsyufsZzcHWhmJiVEev/jWFIZrmOb3CopBaRMs
E8GjcnjXxONGrpz5VDoqCNDjzDtHVKYDupciotEjPhxz2XSiRAdBIs9CbpqqheGy
qqZO6kbqOfYr8++kS8RkCc9AtDShJ382pwkI4IN9yUilCLfAPy4OoPv/JnTn6qfX
6KIPgHKWmt/jgORqU4q87lMwKLJ9Fsmy11NfxS8NiAqBu7qTeh4n+CXFlSuIBm6W
o8wB5rL+STCwdm7M3kzNM1/GlZDNitUlLcLIqk69SzLjL98D/MO0thUKuYV33Rbr
TwOUUEaD0kffiPn+2Qc9snadoWGEWwId/wi6dIFZOMlUBa1geuurL2mdVKJxXDCl
0ABqlYBIuZWmZrYhepK36aoIi1W3Sko+6AbgyvroQhokplI8vEbEG9wW0tnU3HqS
FpsYkhklelh7M4nep7yO54aLw7juyMUD83om1OBPj2d46ZywQWUinOorcVlgehEV
UdQ4tQZclQDfgncX0DEX+yO5L77Jw5CnVxkhDOF+GUY7keSe1KRdZ4Znt6zwxVDa
QzQZfbpLMEyipE0+0Ykbig8IoCgHG5EqcxYFjEGXe6irwhF3g54AzlWd9zRxtd0E
beSh29csbQ==
=7eWS
-END PGP SIGNATURE-

php-8.0.3.tar.bz2
SHA256 hash:
95f8621d9e34f822d2583564c358598dff7346241f839bfa319bbf65bf2eb012
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmA+a2IQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhchAmEACmwuFOyADGNGKO7WwPjIejd9MdMWN9uVQH
DXko5/SGgGB9ledmjS8qN9jiB+quyTXa9LpMSSwc7lb7jqKgafLqFHi0IqP/l53W
Dny67i3OHsVj/qhklXbR4LfajKogZyI2NuPxDyu4p9IdoIe0SRLQD2WkTAZtpg69
1Rt7Q8+Vj/tECKWkKhiTYIXV0Gcrs30GOGoa4s5N1PsIlnHHURFu1p7mwedpLHSA
0ZdheG0zFfdm3SdpjOPJRnK00s9kUxp+q4UmwWw1LXjXMmnIoxsosTIDyWFFi1ww
Zb/CKnLNsKGgwtw34HnGF7NboFNLnGFc/dFzGXQUoXQLgvDjUVXqTX8rb84AjAca
GhQ9YwiktD9PaLaSL+uTOv+aNrbVhvycv9v6WOQBPPdYwfe3pgYcxCbG7y7jxAxS
GofelqCeHl9VjVJW2A/v+TtoW8wVOgrRcNfX4hUoQqOFRB5kZCBdb31Jz/iqePnG
w7l2l/LHk5JTuQzXHTpivM/nI553ZFbHXoo5/KvWpZUJJmAgP0759SmmEvjf2deW
sK1zkqx1GdxWIouS990M58vqN4uPevlyFU2qIAkl6hN4yTGHoBxjQeKp2IFIqcj6
/QoLLttpCk3XCqzogcIcFavE0zVLZ6X7cuiiQvE73YBam4uwWqnUH6SctIjUGVRX
7hQ0eiYuWA==
=ayDO
-END PGP SIGNATURE-

php-8.0.3.tar.xz
SHA256 hash:
c9816aa9745a9695672951eaff3a35ca5eddcb9cacf87a4f04b9fb1169010251
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmA+a2IQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcoOxD/9ZnUlBHrJM3BhDbCl6mldAHBkQc4NOWctM
gJbbvguSMPn8U2Xe6bqpMedFGaK25Dw2UhwV9AzNDsFzbAJj9c16NxhFNjiIhaqu
hiyEa+rdz/1lxbnVrIhN6iCj9c3ucW+BXr+MApS9Rs6zDxITDzZ59WpmYAOipEgo
ejsV2LTWEfeodwMiMBNwIgx2CMWSLr5Y5ea8D4hyIwryGXgObFvrzDfnD35xXp40
pvw4e1ag2UKdAYJJqkL25OvH54sRSyG50Wa1bB1DAY05L7QQBR16FTB35858L70X
rCDw/IpTZJprBmF0XBQWBJNLYt8u+x+1+zRBopkpA8baSeHes+tXbwMR6mJZErtv
8BCcq4MzQ6DF/mHI9bPpJIePgJm4KfXaCBUHoXp5fBn2h8hUlWoDJ7nzGhds4/G5
lPKRX6NyPFMep3I8/YbDJM5D10IOD2IxrV8Og7PYltMjfKYTjJv5iD2i6bAi46lP
NNY7IQ+917No8dy52MXfs2R4RHePP/cLYWsZPHtUwBlVK9uMUCniD6udf+MhfWq7
t54RzyXrg8k0eGgGdKduoYVdxGB4Q3L7trqRwpb7ycI59DMVQ7a5s9YpZ5tNBaTn
tIc/T7jhd+vn5ELA6QvqDw9S4pJ6keXsLAd/YjkHUPcL1DihwLA6+dFvh07ie+vC
ccuqbmRbXA==
=IXBf
-END PGP SIGNATURE-

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[G. P. B.]

On Thu, 4 Mar 2021 at 21:53, Christoph M. Becker  wrote:

> On 04.03.2021 at 18:46, G. P. B. wrote:
>
> > On Thu, 4 Mar 2021 at 16:06, AllenJB  wrote:
> >
> >> On a related note I dislike "documentation burden" as an argument
> >> against improvements. I obviously understand "open source, volunteers,
> >> translations, etc" but I've heard this a few times now as an argument
> >> against fixing various issues (another example is that many functions in
> >> the manual document that they can return false, but there's absolutely
> >> no explanation as to when this can occur except a single paragraph that
> >> lives on its own page that nobody is ever likely to find if they don't
> >> already know it exists and you can't tell which functions it actually
> >> applies to even if you do). Obviously the project doesn't, but if you
> >> followed this for everything (to the extreme), you'd never introduce any
> >> new functionality because it would mean adding more documentation pages.
> >> If this is an issue, does the project need to consider if there are
> >> better ways to handle documentation?
> >>
> >
> > The matter of fact is that at this time there is mainly 1 person which
> > solely
> > works on the documentation, and that is Christoph M. Becker (aka cmb)
> > with some occasional contribution from other individuals (me included)
> > even with an issue tracker we are far from having all the changes for
> PHP 8
> > documented, and even some PHP 7 behaviour is not documented.
> > So documentation burden is a thing, should it prevent feature additions
> to
> > the langage? Obviously not, and we mostly deal with this "just" fine as
> for
> > the docs of the major PHP 8 features were written by their respective RFC
> > authors.
> >
> > A big reason why there was no documentation for false return in the
> > signature is that until recently we did *not* have the capability to
> display
> > union types via the Doc render (PhD), this is now being corrected but is
> > a tedious job of syncing the docs from the officials stubs to also sync
> > named arguments.
>
> Allen's point is about the undocumented return values when calling
> functions with unexpected parameter types (e.g. calling strlen() on an
> object).  There has been quite some discussion about this over the
> years, mostly on the docs mailing list, and I still don't think this
> should be documented for each function individually, because it is by
> definition *undefined* behavior.  If it was defined behavior, we could
> not have elevated this to TypeErrors in PHP 8.0 due to the massive BC
> break.  The fact that this documentation would take years (assuming the
> current bandwidth) is secondary.
>

Ah right, yeah I don't think those should be documented as it is UB, and
iirc it usually throws an E_WARNING with a null return that's why I got
confused by the usage of "false return", apologies.


> Regarding syncing the docs form the official stubs: Máté did a great job
> of semi-automating this, so it isn't *that* much work anymore, but in my
> opinion it is important to also keep the documentation correct for PHP
> 7, and this requires a lot of manual review, and not rarely looking up
> the actual behavior from the implementation – that is quite some work,
> and the reviewer's constant reminder how incomplete and out-dated large
> parts of the manual actually are.
>

> --
> Christoph M. Becker
>

Yes agreed, and I know Maté and you have been working on this a lot,
keeping up the French translation up to date with those changes is
challenging at times because it's not just the function signature change
but there are various amendments to the documentation as a whole.
Yesterday I worked on updating the OpenSSL docs and it took me
about 3h30 to perform the syncing process.

George P. Banyard

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[Rowan Tommins]

On 04/03/2021 14:08, G. P. B. wrote:

This new RFC which I'm proposing is to extend the capability of the error
control operator @ to not just suppress diagnostic messages but also
exceptions.
It can currently be found on GitHub: [1]
https://github.com/Girgias/error-control-operator-exceptions-rfc



Hi George,

This is a really creative approach to this thorny problem, and I think I 
like it, although I'm still working through the implications in my head.



One thing I'd like to call out is that this could be useful in its own 
right, outside of migration strategies.


One of the big downsides of exceptions is that they always cause control 
to jump somewhere else, even when you'd rather they didn't. Joe Duffy in 
an interesting blog post [1] about error handling strategies refers to 
it as "control-flow rather than dataflow".


For instance, if you start with this:

$foo = doSomething() + $bar;

If doSomething() throws an exception, and you want to default to just 
$bar, you have to write this:


try {
   $foo = doSomething() + $bar;
}
catch ( SomeException $e ) {
   $foo = $bar;
}

What you really want is to catch the exception, but not break the flow. 
With this proposal you could:


$foo = ( @doSomething() ?? 0 ) + $offset;


Which leads me to suggest changing this:

> As such @<\Throwable>expression and @expression are identical.

To this:

> When a class list is given, the operator will not suppress raised 
errors (E_WARNING, E_NOTICE, etc).  So @<\Throwable>expression will 
suppress all possible Exceptions, it does not have the same behaviour as 
@expression.


This makes the operator useful even in situations where you want normal 
error handling behaviour (e.g. logging) for Warnings and Notices, but 
want to force an exception back into "dataflow style".



[1] http://joeduffyblog.com/2016/02/07/the-error-model/

Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[Christoph M. Becker]

On 04.03.2021 at 18:46, G. P. B. wrote:

> On Thu, 4 Mar 2021 at 16:06, AllenJB  wrote:
>
>> On a related note I dislike "documentation burden" as an argument
>> against improvements. I obviously understand "open source, volunteers,
>> translations, etc" but I've heard this a few times now as an argument
>> against fixing various issues (another example is that many functions in
>> the manual document that they can return false, but there's absolutely
>> no explanation as to when this can occur except a single paragraph that
>> lives on its own page that nobody is ever likely to find if they don't
>> already know it exists and you can't tell which functions it actually
>> applies to even if you do). Obviously the project doesn't, but if you
>> followed this for everything (to the extreme), you'd never introduce any
>> new functionality because it would mean adding more documentation pages.
>> If this is an issue, does the project need to consider if there are
>> better ways to handle documentation?
>>
>
> The matter of fact is that at this time there is mainly 1 person which
> solely
> works on the documentation, and that is Christoph M. Becker (aka cmb)
> with some occasional contribution from other individuals (me included)
> even with an issue tracker we are far from having all the changes for PHP 8
> documented, and even some PHP 7 behaviour is not documented.
> So documentation burden is a thing, should it prevent feature additions to
> the langage? Obviously not, and we mostly deal with this "just" fine as for
> the docs of the major PHP 8 features were written by their respective RFC
> authors.
>
> A big reason why there was no documentation for false return in the
> signature is that until recently we did *not* have the capability to display
> union types via the Doc render (PhD), this is now being corrected but is
> a tedious job of syncing the docs from the officials stubs to also sync
> named arguments.

Allen's point is about the undocumented return values when calling
functions with unexpected parameter types (e.g. calling strlen() on an
object).  There has been quite some discussion about this over the
years, mostly on the docs mailing list, and I still don't think this
should be documented for each function individually, because it is by
definition *undefined* behavior.  If it was defined behavior, we could
not have elevated this to TypeErrors in PHP 8.0 due to the massive BC
break.  The fact that this documentation would take years (assuming the
current bandwidth) is secondary.

Regarding syncing the docs form the official stubs: Máté did a great job
of semi-automating this, so it isn't *that* much work anymore, but in my
opinion it is important to also keep the documentation correct for PHP
7, and this requires a lot of manual review, and not rarely looking up
the actual behavior from the implementation – that is quite some work,
and the reviewer's constant reminder how incomplete and out-dated large
parts of the manual actually are.

--
Christoph M. Becker

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

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Derick Rethans]

On 4 March 2021 20:22:37 GMT, Dmitry Stogov  wrote:
>I can't reproduce this on Linux.
>
>[dmitry@tpl2 xdebug]$ php run-xdebug-tests.php -d opcache.enable=1 -d
>opcache.enable_cli=1 -d opcache.optimization_level=-1
>tests/tracing/functrace_typed_properties.phpt
>
>...
>PHP_VERSION : 8.1.0-dev
>...
>PASS Test for function traces with typed properties
>[tests/tracing/functrace_typed_properties.phpt]
>...


That's curious. I'm locally on Debian Linux, and Azure pipelines is on OSX. How 
can we figure this out? Want to do a screenshare or something? Perhaps it's a 
compiler issue? I'm building in debug mode FWIW. And see it with and without 
ZTS. 

Did you try my one liner without xdebug involved at all too?

cheers,
Derick

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

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Dmitry Stogov]

I can't reproduce this on Linux.

[dmitry@tpl2 xdebug]$ php run-xdebug-tests.php -d opcache.enable=1 -d
opcache.enable_cli=1 -d opcache.optimization_level=-1
tests/tracing/functrace_typed_properties.phpt

...
PHP_VERSION : 8.1.0-dev
...
PASS Test for function traces with typed properties
[tests/tracing/functrace_typed_properties.phpt]
...

Thanks. Dmitry

On Thu, Mar 4, 2021 at 9:43 PM Derick Rethans  wrote:

> Hi,
>
> It's not just my own build, see this one on OSX on Azure Pipelines (line
> 427):
>
>
> https://dev.azure.com/php-xdebug/Xdebug/_build/results?buildId=388=logs=fa4207ea-b23d-55f8-a438-8fcfe0ff1a84=a376e1dc-bcfe-530b-98ce-61c964f8af0f=425
>
> Which is a build from scratch.
>
> And I've locally also just rebuild from scratch, but still getting the
> same result.
>
> My build log:
> http://derickrethans.nl/files/dump/master.log
>
> My configure line:
> './configure'  '--prefix=/usr/local/php/master' '--enable-debug'
> '--with-gettext' '--with-gd' '--enable-gd' '--with-jpeg'
> '--without-freetype' '--with-jpeg-dir=/usr' '--without-freetype-dir'
> '--with-mysql=mysqlnd' '--enable-bcmath' '--with-readline' '--with-openssl'
> '--without-esmtp' '--with-curl' '--with-sodium' '--with-ffi'
> '--with-mysqli' '--enable-pcntl' '--enable-sockets' '--enable-zip'
> '--with-zip' '--enable-memory-limit' '--with-mcrypt' '--with-libxml'
> '--enable-libxml' '--with-iconv' '--enable-wddx' '--enable-calendar'
> '--with-sqlite3' '--enable-spl' '--enable-pdo' '--with-pdo-mysql'
> '--with-pdo-sqlite' '--with-ctype' '--with-bz2' '--enable-mbstring'
> '--with-mime-magic' '--with-xmlrpc' '--with-zlib'
> '--disable-zend-memory-manager' '--with-esmtp' '--with-xsl' '--enable-exif'
> '--enable-soap' '--enable-ftp' '--enable-intl' '--enable-opcache'
> '--enable-fpm' '--enable-fileinfo' '--with-pear'
>
> cheers,
> Deric
>
> On Thu, 4 Mar 2021, Dmitry Stogov wrote:
>
> > I suppose, something is wrong with your build.
> > This code works fine for me.
> > Please, try full rebuild.
> >
> > Thanks. Dmitry.
> >
> > On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:
> >
> > > Hi,
> > >
> > > turns out that this test fails even without Xdebug even loaded, so it's
> > > not something on my side :-)
> > >
> > > Just run it as:
> > >
> > > wget
> > >
> https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> > > -O xdebug_var_dump_typed_properties-text.php
> > > php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> > > "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> > > xdebug_var_dump_typed_properties-text.php
> > >
> > > Result:
> > >
> > > php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> > > zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> > > Aborted
> > >
> > >
> > > cheers,
> > > Derick
> > >
> > >
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Rowan Tommins]

On 04/03/2021 13:17, Nikita Popov wrote:


A disadvantage of narrowing the definition in such a fashion is that 
it introduces a discrepancy with (float) casts. I believe these 
currently recognize the same values, with the exception that (float) 
discards trailing garbage.



I don't think that's a big problem; as you say, explicit casts are 
already more lax than implicit ones, and that's always going to be the 
case in some sense, because they never "fail". Opinions may vary, though.





Another disadvantage is that exponential notation is commonly returned 
for large numbers by various data source -- e.g. if you stored a large 
float in a database, I'd expect you'd get it back in exponential 
notation (if you get it back as a string). This means that your code 
could suddenly break because the range of a value passes some 
heuristic threshold for how it gets printed.



That may be a more compelling reason, at least given backwards 
compatibility requirements. I don't know how common that is, but it 
certainly sounds plausible.


Regards,

--
Rowan Tommins
[IMSoP]

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

[PHP-DEV] PHP 7.4.16 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.16. This is a security bug fix release.

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

For source downloads of PHP 7.4.16 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.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.



php-7.4.16.tar.gz
SHA256 hash: ef2d2b463fc3444895ec599337b663a8832c6ade148d9832417e59aa2b9e93da
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmA+HZkACgkQkQ3rRvU+
oxJdVQ//YnwUl7JfwPLjjXIMgDoVwH5L9mU3ZLfgRLZEXMVnssNjnGB35hU0XzOB
vPBewA6XUK/i4nvHr9lbCVI7A9WOSs4OEvOf+zLIIindJAgheJYizo9nxacek1Wj
AurDz/dw6uPJb5jkHtm8V3S1FGm1l1JqOpF0/o22cFvOp4371duqw+EPQvudL74V
J0l9tKio3AILNFGqEqv1/+byT0YjBO3l7PejmiijcNqw+xIYnrkY3jIxDEdXPSHg
8K+lYHN61ghlAgmZO4SXQEvIhnus87QzG04u5WQ6OXHCEGfyAsiPugRAkzhDubv8
yKHqM6ut5Fx1ee4VlhiPQS+LABQBVctx6gUYYUgF0se9gBRPxcOPegDMWXu4P2Tn
VCwY5WIcercXuniZ1wGAdth9yd/iu77rCw8r6ZfakKYLoUJ6kz3Qs/JG5gIcUmAd
A9sqa952j0lJ8hs7jNQJaKv/Fd/2BQYZr01WE9VO4HyurWpaabN5WzbzjMD5BXVl
u2LEvRT6VMOWg5/ragAGerccJKZg7xVkzTibOHCnJwnbUeZ0h2si7CzSegZxeWEx
plA/lGG0NaxDVwoLz39kLz+DQs+DM/y3CmSc5QpObdslZlA/xm2BAj4OXv82gRSf
j5hGV6CI2UUHX2iVNDzOklRhE/kr25nDHaUHaWljaJy5fvS0Uj4=
=uDK/
-END PGP SIGNATURE-

php-7.4.16.tar.bz2
SHA256 hash: 85710f007cfd0fae94e13a02a3a036f4e81ef43693260cae8a2e1ca93659ce3e
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmA+HZwACgkQkQ3rRvU+
oxJmIQ//fsuw6pzvHA+iCs+Mk9nxwz2HGJsNz6SBdRlA29AuQrpy95P3moSLkaJw
UVO+dzF1zN93j7pDyr5fJutGMfHo92B5gaVz7zD6Z4S/fr3xCmSKauRh/SaMHtvD
DQ5LCLkZ4Y6HOYiMX7wqGHTagEzMlP+kYVem7ku1c6edniOgC37H6MNvaAM9RStF
Z0sboBzal7h0qiQzyRe9DBC+wC21SYWp/evMivfoBsBcdObnGu7N8oH/dhmwY69f
cIzUJ60UsuK88EBd32u/pklg1gmNEjCARE2acW8IpFHLG4/RlDB323kBtdwJp2H+
EG/nEyBidVVjfILTqHQ0Q/qHxT/MjSc3J54ezNfQi8Q26/W76YWYcnyiFOBYnNM+
FXlEueGPOPY8bonsW1WXdOB9QwHZdlvb2kIGis6PPDa5IfeDkVd0ASCGSuXS6OQq
R5gpxKWo2TcxBbSBWQiKLWNGKtYzmvVIw7QMO3f9nTQ/Ab3+uK+6yHQZb2G0mJ4n
TXqifABLN/ZlOqrOq9aAWkE72zjAtOnaKG/+Te2NuG7zMXCAfMhhL35oR5yb1li2
yIG7qsr+p3z1d7VtvghYXF7OmvkDzmtp/hpFvQl2/t9nf0b0QP/ZbbkOWtwSsVKk
ICSITafKVmK4cJLoOsieomjAjVqAQKjgPnPTRVmTJgLayf89alU=
=nR/i
-END PGP SIGNATURE-

php-7.4.16.tar.xz
SHA256 hash: 1c16cefaf88ded4c92eed6a8a41eb682bb2ef42429deb55f1c4ba159053fb98b
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmA+HZ0ACgkQkQ3rRvU+
oxK/0w/6AjdMWqmigeuehEGqygWbjWeWAXO4fdX3rCxZoJh4dxBdsKW3GPQ9KDh1
Tpkmd0xbyN8R2AV3+7du1UbakHLYnmRnOJK9xByOoDSoWG6QvXUOZ5l4A6KQCFZo
UqLxff8tPoW+X1lgvZtrivEI1Q4l643RS6t6+O96mjzoSitxKPNcO7m9zOq2zprG
DvLJZgl74+lPX9zbMqj2VeB0Vmd461919zR7HB7e+VgB0VOy3NSZSn8FydtGPCmH
GAlNcYC6g96CRYe1afM1uGwlWxrg7EqaSghpt9PlclxetH3CAHwrQrHUQPdlIorw
bv97pIVbHtmZBKpwLHqiY35ui8V/vhJJCmVUNpu1hjeWx7H7a6A5CjGUCrQ+glTV
Ia1+p1yqfCtoaYOHA6CKGNSYT7a4OuLZC1HvNtjjEZkdBI8rYkVMkPmYLJIxseNK
KxJEYxIYI2AyMatX60C2h5bgaY7a0V2ohhDrMH8jeLLuB5f1k3a2d3uuXdlL3Al2
W5Z7rRnQN+ZE7p7A8fCAzXTvT1Dpt13ltLMEygcJ8lClOVMWvCYlDYIg5wMHfZ5y
PqSzv09CX5zYsF4px4QmUy3zandKc5Ir+pzU83D6XGXDPoZJ3XX5qTTtCTLtUBxu
4fKTs5yXEVqZUZHWr2tH2woQkrRDRa4OXTzo3gvZ1jr81OHtsq8=
=rQLI
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Derick Rethans]

Hi,

It's not just my own build, see this one on OSX on Azure Pipelines (line 
427):

https://dev.azure.com/php-xdebug/Xdebug/_build/results?buildId=388=logs=fa4207ea-b23d-55f8-a438-8fcfe0ff1a84=a376e1dc-bcfe-530b-98ce-61c964f8af0f=425

Which is a build from scratch.

And I've locally also just rebuild from scratch, but still getting the 
same result.

My build log:
http://derickrethans.nl/files/dump/master.log

My configure line:
'./configure'  '--prefix=/usr/local/php/master' '--enable-debug' 
'--with-gettext' '--with-gd' '--enable-gd' '--with-jpeg' '--without-freetype' 
'--with-jpeg-dir=/usr' '--without-freetype-dir' '--with-mysql=mysqlnd' 
'--enable-bcmath' '--with-readline' '--with-openssl' '--without-esmtp' 
'--with-curl' '--with-sodium' '--with-ffi' '--with-mysqli' '--enable-pcntl' 
'--enable-sockets' '--enable-zip' '--with-zip' '--enable-memory-limit' 
'--with-mcrypt' '--with-libxml' '--enable-libxml' '--with-iconv' 
'--enable-wddx' '--enable-calendar' '--with-sqlite3' '--enable-spl' 
'--enable-pdo' '--with-pdo-mysql' '--with-pdo-sqlite' '--with-ctype' 
'--with-bz2' '--enable-mbstring' '--with-mime-magic' '--with-xmlrpc' 
'--with-zlib' '--disable-zend-memory-manager' '--with-esmtp' '--with-xsl' 
'--enable-exif' '--enable-soap' '--enable-ftp' '--enable-intl' 
'--enable-opcache' '--enable-fpm' '--enable-fileinfo' '--with-pear'

cheers,
Deric

On Thu, 4 Mar 2021, Dmitry Stogov wrote:

> I suppose, something is wrong with your build.
> This code works fine for me.
> Please, try full rebuild.
> 
> Thanks. Dmitry.
> 
> On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:
> 
> > Hi,
> >
> > turns out that this test fails even without Xdebug even loaded, so it's
> > not something on my side :-)
> >
> > Just run it as:
> >
> > wget
> > https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> > -O xdebug_var_dump_typed_properties-text.php
> > php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> > "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> > xdebug_var_dump_typed_properties-text.php
> >
> > Result:
> >
> > php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> > zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> > Aborted
> >
> >
> > cheers,
> > Derick
> >
> >
> 

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Dmitry Stogov]

I suppose, something is wrong with your build.
This code works fine for me.
Please, try full rebuild.

Thanks. Dmitry.

On Thu, Mar 4, 2021 at 9:00 PM Derick Rethans  wrote:

> Hi,
>
> turns out that this test fails even without Xdebug even loaded, so it's
> not something on my side :-)
>
> Just run it as:
>
> wget
> https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
> -O xdebug_var_dump_typed_properties-text.php
> php -n -dzend_extension=opcache -d "opcache.enable=1" -d
> "opcache.enable_cli=1" -d "opcache.optimization_level=-1" -f
> xdebug_var_dump_typed_properties-text.php
>
> Result:
>
> php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
> Aborted
>
>
> cheers,
> Derick
>
>

[PHP-DEV] Re: Recent changes to opcache cause crashes

[Derick Rethans]

Hi,

turns out that this test fails even without Xdebug even loaded, so it's 
not something on my side :-)

Just run it as:

wget 
https://derickrethans.nl/files/dump/xdebug_var_dump_typed_properties-text.php.txt
 -O xdebug_var_dump_typed_properties-text.php
php -n -dzend_extension=opcache -d "opcache.enable=1" -d "opcache.enable_cli=1" 
-d "opcache.optimization_level=-1" -f xdebug_var_dump_typed_properties-text.php

Result:

php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327: 
zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
Aborted


cheers,
Derick

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

Re: [PHP-DEV] [RFC] Deprecate implicit non-integer-compatible float to int conversions

[G. P. B.]

On Thu, 4 Mar 2021 at 13:23, Andreas Leathley  wrote:

> On 04.03.21 14:07, G. P. B. wrote:
> > This new version of the RFC can be found on the wiki: [2]
> > https://wiki.php.net/rfc/implicit-float-int-deprecate
>
> I like the RFC, but I think the diagnostic messages will be hard to
> understand when they come up in real scripts, especially because they
> can be platform-dependent and can have two different reasons, and
> "non-compatible" is not self-explanatory. Giving a very specific message
> would be more helpful for people experiencing these errors, something like:
>
>   * Implicit conversion to int from float(-string) with fractional part
>   * Implicit conversion to int from float(-string) which is outside of
> int range (=> maybe also mentioning the range of the platform)
>
> (Maybe there are additional possible errors to consider, but those two
> seem two obvious possibilities)
>

The other cases would be converting from infinity (+ or -) or a NaN value.

But having specific messages is a reasonable enhancement but does make
the implementation more complicated as one needs to determine what is
causing
the incompatibility.

I'll have a think about this.

Best,

George P. Banyard

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[G. P. B.]

On Thu, 4 Mar 2021 at 16:06, AllenJB  wrote:

>
> On 04/03/2021 14:08, G. P. B. wrote:
> > Hello internals,
> >
> > This new RFC which I'm proposing is to extend the capability of the error
> > control operator @ to not just suppress diagnostic messages but also
> > exceptions.
> > It can currently be found on GitHub: [1]
> > https://github.com/Girgias/error-control-operator-exceptions-rfc
> >
> > The main motivation for this is to provide a path to migrate in a
> backwards
> > compatible manner away from diagnostics such as E_WARNING to the use of
> > exceptions without breaking 99% of PHP code which has been written in the
> > last 25years.
> >
> > This proposal on it's own would not be sufficient to trigger such a
> change
> > for extensions but in combination with another proposal to introduce a
> > `throw_on_error` declare [2] it could provide a bridge for a gradual
> > transition to the use of more exceptions internally.
> >
> > Although I'm not thrilled with the idea of shoving more functionality
> into
> > @ I don't see any other way, and thus I think it a necessary evil to
> > improve the long term health of the PHP project.
> >
> > Feedback on this RFC and different ideas on how to tackle this topic are
> > highly appreciated and welcomed.
> >
> > Best regards,
> >
> > George P. Banyard
> >
> > [1] https://github.com/Girgias/error-control-operator-exceptions-rfc
> > [2] Draft RFC for throw_on_error declare
> > https://github.com/Girgias/php-rfc-throw-on-error-declare
>
>
>  > as the I/O API has been revamped within the SPL extension but the
> usage of the traditional I/O functions remains the de facto standard
> within the community.
>
> I don't think that this is really an argument for anything. The SPL
> options aren't obvious - I would wager that many, most even, PHP
> developers barely even know SPL exists. The SPL options aren't pushed
> anywhere in the manual that I'm aware of (for example, the manual page
> for dir() doesn't even mention FilesystemIterator / DirecrtoryIterator
> in any way).
>

Maybe, or maybe redesigning an API and rewriting code is suboptimal.
But maybe it's also the fact that the documentation doesn't signal the
alternatives enough due to lack of documentation maintainers which
apparently you don't think it is an issue but I address this below.

But in any ways there are over 2500 error/warning/notices in bundled
extensions, it is *not* just an I/O issue. But the I/O functions do have
somewhat of an alternative which has failed, reasons for that are up
to debate.


> Many developers are already using Safe and similar libraries to get
> "standard library but with exceptions". If this was available in core
> and at least prominently mentioned, if not recommended in the manual
> (could we have a "note box" that's not quite a deprecation notice, but a
> "we strongly urge you to consider this method" in a similar fashion, if
> we don't already?)
>
> If the manual did a similarly better job of recommending SPL ways of
> doing things, I'm sure they'd get used more too.
>
> Would it make sense in some areas such as file operations to have more
> "topic oriented" documentation than the current pure function / class
> listing methodology the manual currently uses? (This might make it
> easier to point out alternatives or make recommendations)
>

The docs are already arranged in "topic oriented" way, look at the function
reference page: https://www.php.net/manual/en/funcref.php


> On a related note I dislike "documentation burden" as an argument
> against improvements. I obviously understand "open source, volunteers,
> translations, etc" but I've heard this a few times now as an argument
> against fixing various issues (another example is that many functions in
> the manual document that they can return false, but there's absolutely
> no explanation as to when this can occur except a single paragraph that
> lives on its own page that nobody is ever likely to find if they don't
> already know it exists and you can't tell which functions it actually
> applies to even if you do). Obviously the project doesn't, but if you
> followed this for everything (to the extreme), you'd never introduce any
> new functionality because it would mean adding more documentation pages.
> If this is an issue, does the project need to consider if there are
> better ways to handle documentation?
>

The matter of fact is that at this time there is mainly 1 person which
solely
works on the documentation, and that is Christoph M. Becker (aka cmb)
with some occasional contribution from other individuals (me included)
even with an issue tracker we are far from having all the changes for PHP 8
documented, and even some PHP 7 behaviour is not documented.
So documentation burden is a thing, should it prevent feature additions to
the langage? Obviously not, and we mostly deal with this "just" fine as for
the docs of the major PHP 8 features were written by their respective RFC
authors.

A big reason why there 

Re: [PHP-DEV] [RFC] New in initializers

[Larry Garfield]

On Thu, Mar 4, 2021, at 7:53 AM, Nikita Popov wrote:

> I've added a section that describes reflection methods. It works exactly as
> you say.
> 
> There is one interesting case though: How should
> ReflectionObject::newInstanceWithoutConstructor() work? In the current
> implementation, it will still evaluate the property defaults, including new
> expressions. This makes sense to me, but I can also see an argument that
> this method should not evaluate them -- however, in that case I believe it
> should not initialize any properties at all (leave them in "uninitialized"
> state). Populating property default values depending on what kind of
> expression they contain seems like a no-go to me.
> 
> @Ben Ramsey: Yes, it's possible to use nested new. Generally, all supported
> constant expressions can be freely combined.
> 
> Regards,
> Nikita

Would that then end up allowing enum cases to have an object backing value?

enum Suit {
  case Hearts = new Heart;
  case Spades = new Spade;
}

Or is there something else that would prevent that?  (I know Ilija ran into 
some complications there.)

Overall, I think the benefit to attributes alone justifies this RFC.  Endorse.

--Larry Garfield

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

Re: [PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[AllenJB]

On 04/03/2021 14:08, G. P. B. wrote:

Hello internals,

This new RFC which I'm proposing is to extend the capability of the error
control operator @ to not just suppress diagnostic messages but also
exceptions.
It can currently be found on GitHub: [1]
https://github.com/Girgias/error-control-operator-exceptions-rfc

The main motivation for this is to provide a path to migrate in a backwards
compatible manner away from diagnostics such as E_WARNING to the use of
exceptions without breaking 99% of PHP code which has been written in the
last 25years.

This proposal on it's own would not be sufficient to trigger such a change
for extensions but in combination with another proposal to introduce a
`throw_on_error` declare [2] it could provide a bridge for a gradual
transition to the use of more exceptions internally.

Although I'm not thrilled with the idea of shoving more functionality into
@ I don't see any other way, and thus I think it a necessary evil to
improve the long term health of the PHP project.

Feedback on this RFC and different ideas on how to tackle this topic are
highly appreciated and welcomed.

Best regards,

George P. Banyard

[1] https://github.com/Girgias/error-control-operator-exceptions-rfc
[2] Draft RFC for throw_on_error declare
https://github.com/Girgias/php-rfc-throw-on-error-declare



> as the I/O API has been revamped within the SPL extension but the 
usage of the traditional I/O functions remains the de facto standard 
within the community.


I don't think that this is really an argument for anything. The SPL 
options aren't obvious - I would wager that many, most even, PHP 
developers barely even know SPL exists. The SPL options aren't pushed 
anywhere in the manual that I'm aware of (for example, the manual page 
for dir() doesn't even mention FilesystemIterator / DirecrtoryIterator 
in any way).


Many developers are already using Safe and similar libraries to get 
"standard library but with exceptions". If this was available in core 
and at least prominently mentioned, if not recommended in the manual 
(could we have a "note box" that's not quite a deprecation notice, but a 
"we strongly urge you to consider this method" in a similar fashion, if 
we don't already?)


If the manual did a similarly better job of recommending SPL ways of 
doing things, I'm sure they'd get used more too.


Would it make sense in some areas such as file operations to have more 
"topic oriented" documentation than the current pure function / class 
listing methodology the manual currently uses? (This might make it 
easier to point out alternatives or make recommendations)



On a related note I dislike "documentation burden" as an argument 
against improvements. I obviously understand "open source, volunteers, 
translations, etc" but I've heard this a few times now as an argument 
against fixing various issues (another example is that many functions in 
the manual document that they can return false, but there's absolutely 
no explanation as to when this can occur except a single paragraph that 
lives on its own page that nobody is ever likely to find if they don't 
already know it exists and you can't tell which functions it actually 
applies to even if you do). Obviously the project doesn't, but if you 
followed this for everything (to the extreme), you'd never introduce any 
new functionality because it would mean adding more documentation pages. 
If this is an issue, does the project need to consider if there are 
better ways to handle documentation?


Are there things the project could implement to improve documentation 
contributions and recruit more translators (something along the lines of 
"bug days" or "Season of Docs"; this might be easier to implement now 
that the docs are in Git(Hub))



With regards to the suggested implementations, I would prefer the 
improved library with exceptions option. I wouldn't like to see yet 
another method of error handling introduced to the standard library 
(such as the Go 2 returns method) - it already has too many. Things have 
been moving in a good direction recently with everything moving toward 
Throwables. I think reversing that trend is a mistake.



Potentially crazy thought: Running with the "improved standard library" 
idea, could this be made easier for developers to use by implementing a 
"use fallback namespace" statement. While PHP currently falls back to 
root / namespace, if the new standard library were - purely for example, 
I'm sure others can come up with a better name - under the namespace 
"/PHP/standard/", developers could add "use fallback namespace 
/PHP/standard/;" to the top of their scripts along with the other use 
statements, and PHP would then try that namespace before falling back 
further to / when encountering undefined classes.


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

Re: [PHP-DEV] [RFC] New in initializers

[Nikita Popov]

On Thu, Mar 4, 2021 at 4:26 PM Gabriel O 
wrote:

>
> On Wed, 3 Mar 2021 at 16:04, Nikita Popov  wrote:
>
>> Hi internals,
>>
>> I would like to propose allowing the use of "new" inside various
>> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>>
>> In particular, this allows specifying object default values for properties
>> and parameters, and allows the use of objects as attribute arguments.
>>
>> The RFC is narrow in scope in that it only adds support for "new". An
>> extension to other call kinds should be straightforward though.
>>
>> Regards,
>> Nikita
>>
>
>  Does this support anonymous classes? RFC should probably mention that.
>

Anonymous classes are not supported. I've added an explicit mention of that
fact.

Regards,
Nikita

Re: [PHP-DEV] [RFC] New in initializers

[Gabriel O]

On Wed, 3 Mar 2021 at 16:04, Nikita Popov  wrote:

> Hi internals,
>
> I would like to propose allowing the use of "new" inside various
> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>
> In particular, this allows specifying object default values for properties
> and parameters, and allows the use of objects as attribute arguments.
>
> The RFC is narrow in scope in that it only adds support for "new". An
> extension to other call kinds should be straightforward though.
>
> Regards,
> Nikita
>

 Does this support anonymous classes? RFC should probably mention that.

Re: [PHP-DEV] [RFC] New in initializers

[Nikita Popov]

On Wed, Mar 3, 2021 at 7:04 PM Alexandru Pătrănescu 
wrote:

>
> On Wed, Mar 3, 2021 at 5:49 PM Nikita Popov  wrote:
>
>> On Wed, Mar 3, 2021 at 4:28 PM Alexandru Pătrănescu 
>> wrote:
>>
>>> Hi,
>>>
>>> This looks very nice and I'm interested in further steps where not only
>>> new can be used :).
>>>
>>> The only thing I think it would be good to improve is to have a
>>> deterministic order for running initialization.
>>> Yes, this can be done at a later point, I guess. But maybe there is
>>> already an order of initialization right now and people would start
>>> replying on it and it would be good to mention it.
>>> Or maybe I didn't understand what this refers to: "this is not
>>> guaranteed behavior, and code should not rely on a specific point of
>>> evaluation."
>>>
>>
>> Which particular cases would you like to see specified? There are five
>> cases that have clearly defined behavior, and that I could explicitly
>> specify if desired:
>>
>>  * Non-class constants: Are evaluated immediately when declared (i.e.
>> when control flow reaches the declaration).
>>  * Attribute arguments: Are evaluated in the order of the arguments.
>>  * Parameter defaults: Are evaluated in the order of the parameters.
>>  * Non-static property defaults: Are evaluated in order of declaration,
>> with parent properties first. The constructor is run after defaults are
>> evaluated.
>>  * Static variables: Are evaluated immediately when declared (i.e. when
>> control flow reaches the declaration).
>>
>> And then there are the two problematic cases: Class constants and static
>> properties. Currently, PHP evaluates these semi-lazily. All class constants
>> and static properties are evaluated at the same time, on first "use" of the
>> class. I would consider this to be something of an implementation detail.
>> That's what I meant by that sentence.
>>
>> Now, if we allow "new" expressions, then I could see an argument in favor
>> of requiring class constant and static property initializers to be
>> evaluated eagerly, i.e. directly after the class has been declared. This
>> would be a (minor) backwards-compatibility break, because invalid
>> constant/property declarations would error out immediately, even if they
>> don't get used. However, I do think that this would be the most predictable
>> behavior once potentially side-effecting expressions are involved (we
>> already support side-effecting expressions right now, but less explicitly).
>>
>>
> Yes, this is what I was thinking about, to have a clear stated order of
> initialization.
> Yes, I agree that class constants and static properties should be eagerly
> declared when class is declared.
>
> So the order would be:
> - constants and static variables, when reaching the statement that does
> the declaration
> - class constants and static property, when class is declared, in order of
> their declaration in the class
> - instance property, when class is instantiated, in order of their
> declaration in the class, before construct
> - parameter defaults and attribute arguments defaults, when
> function/method/attribute construct is called, in order of the declared
> parameter/arguments.
>

If we wanted to eagerly evaluate class constants and static properties when
the class is declared, I wonder what the expected behavior would be if
evaluation fails. If you have something like

try {
class A {
const B = new Foo; // Let's assume this throws an Error.
const C = 1;
}
} catch (Error) {}
var_dump(A::C);

then what would happen? Some initial thoughts would be:

1. If evaluation fails, don't declare the class. This is problematic
because we may want to use the class while evaluating, e.g. for a
"self::FOO" default. So I don't think registering the class only after
evaluation is an option. We can also not un-register the class on failure
(technically impossible).

2. If evaluation fails, set the remaining values to UNDEF. For static
properties this will act like an uninitialized typed property, for
constants we'd have to add an error condition for this ("Class constant not
available due to initialization failure").

Also, an unrelated realization that I had is that our trait property
compatibility check currently performs evaluation when checking whether two
properties are the same -- but this seems problematic if the default value
uses "new".

Regards,
Nikita

[PHP-DEV] [RFC] Extend error control operator to suppress exceptions

[G. P. B.]

Hello internals,

This new RFC which I'm proposing is to extend the capability of the error
control operator @ to not just suppress diagnostic messages but also
exceptions.
It can currently be found on GitHub: [1]
https://github.com/Girgias/error-control-operator-exceptions-rfc

The main motivation for this is to provide a path to migrate in a backwards
compatible manner away from diagnostics such as E_WARNING to the use of
exceptions without breaking 99% of PHP code which has been written in the
last 25years.

This proposal on it's own would not be sufficient to trigger such a change
for extensions but in combination with another proposal to introduce a
`throw_on_error` declare [2] it could provide a bridge for a gradual
transition to the use of more exceptions internally.

Although I'm not thrilled with the idea of shoving more functionality into
@ I don't see any other way, and thus I think it a necessary evil to
improve the long term health of the PHP project.

Feedback on this RFC and different ideas on how to tackle this topic are
highly appreciated and welcomed.

Best regards,

George P. Banyard

[1] https://github.com/Girgias/error-control-operator-exceptions-rfc
[2] Draft RFC for throw_on_error declare
https://github.com/Girgias/php-rfc-throw-on-error-declare

Re: [PHP-DEV] [RFC] New in initializers

[Nikita Popov]

On Thu, Mar 4, 2021 at 6:21 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Nikita,
>
> śr., 3 mar 2021, 16:04 użytkownik Nikita Popov 
> napisał:
>
>> Hi internals,
>>
>> I would like to propose allowing the use of "new" inside various
>> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>>
>> In particular, this allows specifying object default values for properties
>> and parameters, and allows the use of objects as attribute arguments.
>>
>> The RFC is narrow in scope in that it only adds support for "new". An
>> extension to other call kinds should be straightforward though.
>>
>
> The reflection mechanism for properties, constants and parameters is not
> described in RFC but I do believe it should for constants part. Correct me
> if I'm wrong there.
>
> The reflection for ReflectionProperty::getDefaultValue the same for
> ReflectionParameter is similar and I get that it possibly should evaluate
> the value on each call. But what about constants which by their nature
> don't change?
> Does that mean that each time ReflectionClass::getConstant is called the
> value is already evaluated and the return value always refer to the same
> object instance. Is that right? I guess it is.
>
> IMO it deserves to be described in the RFC.
>
> In general I love the proposal was especially thinking of it for static
> variables.
>
> Cheers,
> Michał Marcin Brzuchalski
>

I've added a section that describes reflection methods. It works exactly as
you say.

There is one interesting case though: How should
ReflectionObject::newInstanceWithoutConstructor() work? In the current
implementation, it will still evaluate the property defaults, including new
expressions. This makes sense to me, but I can also see an argument that
this method should not evaluate them -- however, in that case I believe it
should not initialize any properties at all (leave them in "uninitialized"
state). Populating property default values depending on what kind of
expression they contain seems like a no-go to me.

@Ben Ramsey: Yes, it's possible to use nested new. Generally, all supported
constant expressions can be freely combined.

Regards,
Nikita

[PHP-DEV] Re: Recent changes to opcache cause crashes when loaded with Xdebug

[Dmitry Stogov]

We already made few significant changes in PHP-8.1.
e.g. most classes and methods are immutable.
It's not allowed to change them (this is the same as before, but now almost
all of them are immutable). Use opcache.protect_memory=1 to catch
potentially wrong modification.

>From the quick look, I don't see how zend_map_ptr_new() may return 0 or 1
at this point.
I'll be able to run xdebug tests only in the middle of the next week.

Thanks. Dmitry.

On Thu, Mar 4, 2021 at 3:41 PM Derick Rethans  wrote:

> Hi,
>
> I've been doing some work on making Xdebug run with PHP 8.1 (master)
> again, and after my fixes
> (https://github.com/xdebug/xdebug/pull/728/files) I am still running
> into a crash (or rather, assert, in opcache):
>
> php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327:
> zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.
>
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x76bc5537 in __GI_abort () at abort.c:79
> #2  0x76bc540f in __assert_fail_base (fmt=0x76d2e128
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x745b7584 "ret
> > 2", file=0x745b7410
> "/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c",
> line=327, function=) at assert.c:92
> #3  0x76bd4662 in __GI___assert_fail (assertion=0x745b7584
> "ret > 2", file=0x745b7410
> "/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c", line=327,
> function=0x745b7810 <__PRETTY_FUNCTION__.6>
> "zend_accel_get_type_map_ptr") at assert.c:101
> #4  0x744a1328 in zend_accel_get_type_map_ptr
> (type_name=0x4021bbb0, scope=0x408beca0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327
> #5  0x744a15a2 in zend_persist_type (type=0x408bf068,
> scope=0x408beca0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:352
> #6  0x744a292a in zend_persist_op_array_ex (op_array=0x408bef00,
> main_persistent_script=0x0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:630
> #7  0x744a34de in zend_persist_class_method (zv=0x408beec0,
> ce=0x408beca0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:765
> #8  0x744a40f8 in zend_persist_class_entry
> (orig_ce=0x57324b28) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:876
> #9  0x744a7047 in zend_accel_persist_class_table
> (class_table=0x408beaf0) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:1225
> #10 0x744a7845 in zend_accel_script_persist (script=0x408be9c0,
> key=0x7fff99e0, key_length=80, for_shm=1) at
> /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:1286
> #11 0x7448c2e3 in cache_script_in_shared_memory
> (new_persistent_script=0x5739a8b0, key=0x408beb88
> "coverage4.inc:2502976:2352312:/home/derick/dev/php/derickr-xdebug/tests/coverage",
> key_length=80,
> from_shared_memory=0x7fff9adc) at
> /home/derick/dev/php/php-src.git/ext/opcache/ZendAccelerator.c:1550
> #12 0x7448f3b2 in persistent_compile_file
> (file_handle=0x7fff9b80, type=2) at
> /home/derick/dev/php/php-src.git/ext/opcache/ZendAccelerator.c:2181
> #13 0x74402461 in xdebug_compile_file (file_handle=0x7fff9b80,
> type=2) at /home/derick/dev/php/derickr-xdebug/src/base/base.c:75
> #14 0x55d8bf25 in compile_filename (type=2, filename=0x408be620)
> at Zend/zend_language_scanner.l:727
> #15 0x55e31b86 in zend_include_or_eval (inc_filename=0x408be620,
> type=2) at /home/derick/dev/php/php-src.git/Zend/zend_execute.c:4270
> #16 0x55e40d13 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER () at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:4697
> #17 0x55e3ba87 in ZEND_USER_OPCODE_SPEC_HANDLER () at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:3019
> #18 0x55eabc4c in execute_ex (ex=0x57334b40) at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:54826
> #19 0x74404838 in xdebug_execute_ex (execute_data=0x57334b40)
> at /home/derick/dev/php/derickr-xdebug/src/base/base.c:765
> #20 0x55eb02b6 in zend_execute (op_array=0x571afcf0,
> return_value=0x0) at
> /home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:59065
> #21 0x55dfba96 in zend_execute_scripts (type=8, retval=0x0,
> file_count=3) at /home/derick/dev/php/php-src.git/Zend/zend.c:1689
> #22 0x55d4e84d in php_execute_script (primary_file=0x7fffd580)
> at /home/derick/dev/php/php-src.git/main/main.c:2489
> #23 0x55f5ad32 in do_cli (argc=88, argv=0x56fb0e10) at
> /home/derick/dev/php/php-src.git/sapi/cli/php_cli.c:964
> #24 0x55f5bd80 in main (argc=88, argv=0x56fb0e10) at
> 

Re: [PHP-DEV] [RFC] Deprecate implicit non-integer-compatible float to int conversions

[Andreas Leathley]

On 04.03.21 14:07, G. P. B. wrote:

This new version of the RFC can be found on the wiki: [2]
https://wiki.php.net/rfc/implicit-float-int-deprecate


I like the RFC, but I think the diagnostic messages will be hard to
understand when they come up in real scripts, especially because they
can be platform-dependent and can have two different reasons, and
"non-compatible" is not self-explanatory. Giving a very specific message
would be more helpful for people experiencing these errors, something like:

 * Implicit conversion to int from float(-string) with fractional part
 * Implicit conversion to int from float(-string) which is outside of
   int range (=> maybe also mentioning the range of the platform)

(Maybe there are additional possible errors to consider, but those two
seem two obvious possibilities)

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Nikita Popov]

On Thu, Mar 4, 2021 at 1:03 PM Rowan Tommins 
wrote:

> On 04/03/2021 10:54, Nikita Popov wrote:
> > The main one that comes to mind is something like '0' == '0.0'. However,
> > the real problem is something else: Comparison behavior doesn't affect
> just
> > == and !=, but also < and >. And I can see how people would want '2' <
> '10'
> > to be true (numeric comparison) rather than false (lexicographical
> > comparison).
>
>
> That's a very good point, and I think the existence of the <=> makes
> this even more complicated.
>
>
> Considering your two options:
>
> > 1. Decouple equality comparison from relational comparison. Don't handle
> > numeric strings for == and !=, but do handle them for <, >, etc.
>
>
> What would then be the result of '0' <=> '0.0'? Would the operator need
> to special case the fact that they are numerically equal but
> lexicographically unequal?
>

Both '0' <=> '0.0' and '0.0' <=> '0' would return 1 in that case, which is
PHP's indication that values are non-comparable. It's definitely not a good
option.


> > 2. Don't allow relational comparison on strings. If you want to compare
> > them lexicographically, use strcmp(), otherwise cast to number first.
>
>
> This is easy to *implement* for the <=> operator, but makes it much less
> useful. Part of the appeal of the operator is that you can write code
> like $sortCallback = fn($a,$b) => $a[$sortField] <=> $b[$sortField];
> without needing different cases for different data types.
>
> Granted, that's not going to use an appropriate sorting collation for
> many languages, but nor is strcmp().
>
>
> I think further narrowing the definition of "numeric string" is a more
> useful course. If we were designing from scratch, the straight-forward
> definition would be:
>
> - all digits: /^\d+$/
> - or, all digits with leading hyphen-minus: /^-\d+$/
> - or, at least one digit, a dot, and at least one more digit: /^\d+\.\d+$/
> - or, as above, but with leading hyphen-minus: /^-\d+\.\d+$/
>
> I think anything beyond that list needs to be carefully justified.
>
> - Leading and trailing spaces are probably OK. Other whitespace
> (newlines, tabs, etc) probably not.
> - Alternative notations like hexadecimal and exponentials are easy to
> have false positive matches, and how common are they in practice?
> - Leading and trailing dots (".5", "1.") might be used sometimes, but
> I'd probably lean against
>
> So, ignoring BC concerns, I would be happy with "numeric string" defined
> as "maybe space, maybe hyphen, some digits, maybe a dot and more digits,
> maybe space", which I think in regex form looks like /^ *-?\d+(\.\d+)? *$/
>

A disadvantage of narrowing the definition in such a fashion is that it
introduces a discrepancy with (float) casts. I believe these currently
recognize the same values, with the exception that (float) discards
trailing garbage.

Another disadvantage is that exponential notation is commonly returned for
large numbers by various data source -- e.g. if you stored a large float in
a database, I'd expect you'd get it back in exponential notation (if you
get it back as a string). This means that your code could suddenly break
because the range of a value passes some heuristic threshold for how it
gets printed.

Regards,
Nikita

[PHP-DEV] Re: timelib inefficiency

[Dmitry Stogov]

hi,

On Thu, Mar 4, 2021 at 3:30 PM Derick Rethans  wrote:

> Hi,
>
> I saw the PRs coming in, I'll reply inline:
>
> On Thu, 4 Mar 2021, Dmitry Stogov wrote:
>
> >
> https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58
>
> As Nikita already commented, this now seems to introduce flakeyness into
> tests.
>
> > And created 3 pull request for timelib:
> >
> > https://github.com/derickr/timelib/pull/98
>
> That looks reasonable. I'm currently working on implementing
> https://github.com/derickr/timelib/issues/14 which will also touch that
> code, so I'll look at it as part of that work.
>
> > https://github.com/derickr/timelib/pull/99
>
> Is incorrect, the tzfile 5 man page says:
>
> Time zone designations should consist of at least three (3) and no
> more
> than six (6) ASCII characters from the set of alphanumerics
>

timelib (timezonedb.h and fallbackmap.h) doesn't have abbreviation longer
than 5 characters, but has single char abbreviations.


>
> I am curious to as to why this routine was called so often though, as
> looking for abbreviations isn't something that should have be be done
> often.
>

Every time you parse a time zone name (including a date with timezone) you
always (except for UTS and GMT) perform a linear search through all entries
listed in timezonedb.h (1128 string comparisons + 1128*2 lowercasing +
1128*2 calls to strlen()), and only then take a look for timezone name,
that may be already cached.


>
> > https://github.com/derickr/timelib/pull/100
>
> This new routine is perhaps faster, but it is also extremely more
> complex, with little comments. It's unlikely I would want to incorporate
> it in its current form.
>

What comments do you like?
We first guess the year dividing days to 365, then check if our guess is
right (number of days from the start of the guessed year fits into this
year), and then continue searching.
This is like a binary search, but with base 365 and the rule to check the
leap year.


> > Please, verify and merge the timelib patches into PHP.
> > Please, let me know if this will take time.
>
> It will certainly take time :-)
>
> > I fixed only the visible, most significant and obvious bottlenecks.
> > It's possible to improve timelib more...
>
> I'm sure it is! The code is 17 years old by now!
>

yeah, this is the problem. Nobody likes to improve it. I'm interested only
because it significantly affects PHP performance.

Thanks. Dmitry.


>
> cheers,
> Derick
>

[PHP-DEV] [RFC] Deprecate implicit non-integer-compatible float to int conversions

[G. P. B.]

Hello internals,

This is a follow-up on the previous thread [1] about my RFC tackling
implicit float to int conversion.
It is now slightly larger in scope as it also pertains to what I call "non
compatible integer floating numbers".

This new version of the RFC can be found on the wiki: [2]
https://wiki.php.net/rfc/implicit-float-int-deprecate

Feedback is as usual welcomed, however I am not interested in changing the
behaviour of explicit casts.
One detail is if this RFC should also allow the usage of int compatible
float strings for string offsets, behaviour which has been removed in PHP
8.0 with the Saner Numeric Strings RFC. [3]

Best regards,

George P. Banyard

[1] "[RFC] Warning for implicit float to int conversions"
https://externals.io/message/113077
[2] https://wiki.php.net/rfc/implicit-float-int-deprecate
[3] https://wiki.php.net/rfc/saner-numeric-strings

[PHP-DEV] Recent changes to opcache cause crashes when loaded with Xdebug

[Derick Rethans]

Hi,

I've been doing some work on making Xdebug run with PHP 8.1 (master) 
again, and after my fixes 
(https://github.com/xdebug/xdebug/pull/728/files) I am still running 
into a crash (or rather, assert, in opcache):

php: /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327: 
zend_accel_get_type_map_ptr: Assertion `ret > 2' failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76bc5537 in __GI_abort () at abort.c:79
#2  0x76bc540f in __assert_fail_base (fmt=0x76d2e128 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x745b7584 "ret > 2", 
file=0x745b7410 
"/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c", 
line=327, function=) at assert.c:92
#3  0x76bd4662 in __GI___assert_fail (assertion=0x745b7584 "ret > 
2", file=0x745b7410 
"/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c", line=327, 
function=0x745b7810 <__PRETTY_FUNCTION__.6> 
"zend_accel_get_type_map_ptr") at assert.c:101
#4  0x744a1328 in zend_accel_get_type_map_ptr (type_name=0x4021bbb0, 
scope=0x408beca0) at 
/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:327
#5  0x744a15a2 in zend_persist_type (type=0x408bf068, scope=0x408beca0) 
at /home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:352
#6  0x744a292a in zend_persist_op_array_ex (op_array=0x408bef00, 
main_persistent_script=0x0) at 
/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:630
#7  0x744a34de in zend_persist_class_method (zv=0x408beec0, 
ce=0x408beca0) at 
/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:765
#8  0x744a40f8 in zend_persist_class_entry (orig_ce=0x57324b28) at 
/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:876
#9  0x744a7047 in zend_accel_persist_class_table 
(class_table=0x408beaf0) at 
/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:1225
#10 0x744a7845 in zend_accel_script_persist (script=0x408be9c0, 
key=0x7fff99e0, key_length=80, for_shm=1) at 
/home/derick/dev/php/php-src.git/ext/opcache/zend_persist.c:1286
#11 0x7448c2e3 in cache_script_in_shared_memory 
(new_persistent_script=0x5739a8b0, key=0x408beb88 
"coverage4.inc:2502976:2352312:/home/derick/dev/php/derickr-xdebug/tests/coverage",
 key_length=80, 
from_shared_memory=0x7fff9adc) at 
/home/derick/dev/php/php-src.git/ext/opcache/ZendAccelerator.c:1550
#12 0x7448f3b2 in persistent_compile_file (file_handle=0x7fff9b80, 
type=2) at /home/derick/dev/php/php-src.git/ext/opcache/ZendAccelerator.c:2181
#13 0x74402461 in xdebug_compile_file (file_handle=0x7fff9b80, 
type=2) at /home/derick/dev/php/derickr-xdebug/src/base/base.c:75
#14 0x55d8bf25 in compile_filename (type=2, filename=0x408be620) at 
Zend/zend_language_scanner.l:727
#15 0x55e31b86 in zend_include_or_eval (inc_filename=0x408be620, 
type=2) at /home/derick/dev/php/php-src.git/Zend/zend_execute.c:4270
#16 0x55e40d13 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER () at 
/home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:4697
#17 0x55e3ba87 in ZEND_USER_OPCODE_SPEC_HANDLER () at 
/home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:3019
#18 0x55eabc4c in execute_ex (ex=0x57334b40) at 
/home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:54826
#19 0x74404838 in xdebug_execute_ex (execute_data=0x57334b40) at 
/home/derick/dev/php/derickr-xdebug/src/base/base.c:765
#20 0x55eb02b6 in zend_execute (op_array=0x571afcf0, 
return_value=0x0) at 
/home/derick/dev/php/php-src.git/Zend/zend_vm_execute.h:59065
#21 0x55dfba96 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/derick/dev/php/php-src.git/Zend/zend.c:1689
#22 0x55d4e84d in php_execute_script (primary_file=0x7fffd580) at 
/home/derick/dev/php/php-src.git/main/main.c:2489
#23 0x55f5ad32 in do_cli (argc=88, argv=0x56fb0e10) at 
/home/derick/dev/php/php-src.git/sapi/cli/php_cli.c:964
#24 0x55f5bd80 in main (argc=88, argv=0x56fb0e10) at 
/home/derick/dev/php/php-src.git/sapi/cli/php_cli.c:1357

To reproduce:
- Check out xdebug from GIT, and switch to the php81-fixes branch:
  git clone g...@github.com:derickr/xdebug.git && cd xdebug && git checkout 
php81-fixes

- Compile and install
  phpize && ./configure  --enable-xdebug-dev && make clean && make all && make 
install

- Run tests:
  OPCACHE=yes php run-xdebug-tests.php
  (This should show the error, and create the .php file used below):

- For an individual test that shows it (with php.ini disabled):
  /usr/local/php/master-zts/bin/php -n -dzend_extension=opcache 
-dzend_extension=xdebug -d "opcache.enable=1" -d "opcache.enable_cli=1" 

[PHP-DEV] Re: timelib inefficiency

[Derick Rethans]

Hi,

I saw the PRs coming in, I'll reply inline:

On Thu, 4 Mar 2021, Dmitry Stogov wrote:

> https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58

As Nikita already commented, this now seems to introduce flakeyness into 
tests.

> And created 3 pull request for timelib:
> 
> https://github.com/derickr/timelib/pull/98

That looks reasonable. I'm currently working on implementing 
https://github.com/derickr/timelib/issues/14 which will also touch that 
code, so I'll look at it as part of that work.

> https://github.com/derickr/timelib/pull/99

Is incorrect, the tzfile 5 man page says:

Time zone designations should consist of at least three (3) and no more
than six (6) ASCII characters from the set of alphanumerics

I am curious to as to why this routine was called so often though, as 
looking for abbreviations isn't something that should have be be done 
often.

> https://github.com/derickr/timelib/pull/100

This new routine is perhaps faster, but it is also extremely more 
complex, with little comments. It's unlikely I would want to incorporate 
it in its current form.

> Please, verify and merge the timelib patches into PHP.
> Please, let me know if this will take time.

It will certainly take time :-)

> I fixed only the visible, most significant and obvious bottlenecks. 
> It's possible to improve timelib more...

I'm sure it is! The code is 17 years old by now!

cheers,
Derick

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

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Rowan Tommins]

On 04/03/2021 10:54, Nikita Popov wrote:

The main one that comes to mind is something like '0' == '0.0'. However,
the real problem is something else: Comparison behavior doesn't affect just
== and !=, but also < and >. And I can see how people would want '2' < '10'
to be true (numeric comparison) rather than false (lexicographical
comparison).



That's a very good point, and I think the existence of the <=> makes 
this even more complicated.



Considering your two options:


1. Decouple equality comparison from relational comparison. Don't handle
numeric strings for == and !=, but do handle them for <, >, etc.



What would then be the result of '0' <=> '0.0'? Would the operator need 
to special case the fact that they are numerically equal but 
lexicographically unequal?




2. Don't allow relational comparison on strings. If you want to compare
them lexicographically, use strcmp(), otherwise cast to number first.



This is easy to *implement* for the <=> operator, but makes it much less 
useful. Part of the appeal of the operator is that you can write code 
like $sortCallback = fn($a,$b) => $a[$sortField] <=> $b[$sortField]; 
without needing different cases for different data types.


Granted, that's not going to use an appropriate sorting collation for 
many languages, but nor is strcmp().



I think further narrowing the definition of "numeric string" is a more 
useful course. If we were designing from scratch, the straight-forward 
definition would be:


- all digits: /^\d+$/
- or, all digits with leading hyphen-minus: /^-\d+$/
- or, at least one digit, a dot, and at least one more digit: /^\d+\.\d+$/
- or, as above, but with leading hyphen-minus: /^-\d+\.\d+$/

I think anything beyond that list needs to be carefully justified.

- Leading and trailing spaces are probably OK. Other whitespace 
(newlines, tabs, etc) probably not.
- Alternative notations like hexadecimal and exponentials are easy to 
have false positive matches, and how common are they in practice?
- Leading and trailing dots (".5", "1.") might be used sometimes, but 
I'd probably lean against


So, ignoring BC concerns, I would be happy with "numeric string" defined 
as "maybe space, maybe hyphen, some digits, maybe a dot and more digits, 
maybe space", which I think in regex form looks like /^ *-?\d+(\.\d+)? *$/



Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Kamil Tekiela]

I actually do a lot of lexicographical comparison with ISO8601 date
strings.
I also have numerical string comparisons, but the truth is I didn't think
they would be cast to integers so that is a potential bug in my code. When
I use < on strings I expect that they will both compare as strings. In
other places, I explicitly cast one or both operands to integers or float.
I do see the problem that many people could use < and > on strings
expecting numerical comparison, but I believe most people expect
lexicographical comparison like me.

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Nikita Popov]

On Thu, Mar 4, 2021 at 11:54 AM Nikita Popov  wrote:

> On Thu, Mar 4, 2021 at 10:54 AM Christian Schneider 
> wrote:
>
>> Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
>> > On Mar 3, 2021, at 14:25, Kamil Tekiela  wrote:
>> >>
>> >> when both are strings then chances are that this is an error.
>> >
>> > Except when comparing two values from sources known to provide numbers
>> as strings, such as form input and database results. :-)
>>
>>
>> This would be a problem for leading zeroes and leading/training spaces,
>> right?
>>
>> Leading zeroes theoretically could happen in databases, leading/training
>> spaces happen in form input and possibly databases.
>> Are there other 'common' cases?
>>
>
> The main one that comes to mind is something like '0' == '0.0'. However,
> the real problem is something else: Comparison behavior doesn't affect just
> == and !=, but also < and >. And I can see how people would want '2' < '10'
> to be true (numeric comparison) rather than false (lexicographical
> comparison).
>
> I generally agree that we should remove the special "numeric string"
> handling for equality comparisons, and I don't think that removing that
> behavior would have a major impact. But we do need to carefully consider
> the impact it has on relational operators. There are two ways I can see
> this going:
>
> 1. Decouple equality comparison from relational comparison. Don't handle
> numeric strings for == and !=, but do handle them for <, >, etc. The
> disadvantage is that comparison results may not be trichotomous, e.g. for
> "0" op "0.0" all of ==, < and > would return false. (To be fair, this can
> already happen in other cases, e.g. non-comparable objects.)
>
> 2. Don't allow relational comparison on strings. If you want to compare
> them lexicographically, use strcmp(), otherwise cast to number first.
> ("Don't allow" here could be a warning to start with.)
>

Regarding the last point, while I think that lexicographical comparison
with explicit < and > operators is pretty uncommon, sorting an array of
strings and expecting lexicographical order probably isn't unusual. While
SORT_STRING can be passed to enforce that, people probably expect that as
the default behavior. So just not allowing relational comparison is not a
great option either.

Nikita

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Nikita Popov]

On Thu, Mar 4, 2021 at 10:54 AM Christian Schneider 
wrote:

> Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
> > On Mar 3, 2021, at 14:25, Kamil Tekiela  wrote:
> >>
> >> when both are strings then chances are that this is an error.
> >
> > Except when comparing two values from sources known to provide numbers
> as strings, such as form input and database results. :-)
>
>
> This would be a problem for leading zeroes and leading/training spaces,
> right?
>
> Leading zeroes theoretically could happen in databases, leading/training
> spaces happen in form input and possibly databases.
> Are there other 'common' cases?
>

The main one that comes to mind is something like '0' == '0.0'. However,
the real problem is something else: Comparison behavior doesn't affect just
== and !=, but also < and >. And I can see how people would want '2' < '10'
to be true (numeric comparison) rather than false (lexicographical
comparison).

I generally agree that we should remove the special "numeric string"
handling for equality comparisons, and I don't think that removing that
behavior would have a major impact. But we do need to carefully consider
the impact it has on relational operators. There are two ways I can see
this going:

1. Decouple equality comparison from relational comparison. Don't handle
numeric strings for == and !=, but do handle them for <, >, etc. The
disadvantage is that comparison results may not be trichotomous, e.g. for
"0" op "0.0" all of ==, < and > would return false. (To be fair, this can
already happen in other cases, e.g. non-comparable objects.)

2. Don't allow relational comparison on strings. If you want to compare
them lexicographically, use strcmp(), otherwise cast to number first.
("Don't allow" here could be a warning to start with.)

Regards,
Nikita

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Christian Schneider]

Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
> On Mar 3, 2021, at 14:25, Kamil Tekiela  wrote:
>> 
>> when both are strings then chances are that this is an error.
> 
> Except when comparing two values from sources known to provide numbers as 
> strings, such as form input and database results. :-)


This would be a problem for leading zeroes and leading/training spaces, right?

Leading zeroes theoretically could happen in databases, leading/training spaces 
happen in form input and possibly databases.
Are there other 'common' cases?

- Chris

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

[PHP-DEV] Re: timelib inefficiency

[Dmitry Stogov]

Hi Derick,

I spent some time looking in the timelib implementation caused slowness in
the Symphony Demo app (https://github.com/symfony/demo)

I committed one patch into ext/date:

https://github.com/php/php-src/commit/b4e9b1846376f562e27a13572a137ec584c13f58

And created 3 pull request for timelib:

https://github.com/derickr/timelib/pull/98
https://github.com/derickr/timelib/pull/99
https://github.com/derickr/timelib/pull/100

These patches make 5% improvement on the Symphony Demo app (100 homepage
requests after warm up, according to callgrind, timezone "Europe/Moscow")

Please, verify and merge the timelib patches into PHP.
Please, let me know if this will take time.

I fixed only the visible, most significant and obvious bottlenecks.
It's possible to improve timelib more...

Thanks. Dmitry.

On Thu, Feb 25, 2021 at 3:21 PM Dmitry Stogov 
wrote:

> Hi Derick,
>
> Please take a look
>
>
> https://github.com/php/php-src/blob/51914610ab8bf75d87e5cdec15bd1b38de7907c5/ext/date/lib/parse_date.re#L684-L700
>
> This code is enormously inefficient. For a single abbr_search(), it calls
> timelib_strcasecmp() more than 1000 times (complete linear search in a huge
> almost ordered array, with repeatable and redundant lowercasing). 11 calls
> to abbr_search() per request in the Symfony Demo application (
> https://github.com/symfony/demo) eat 2% of overall CPU time.
>
> I see some other inefficient patterns in timelib. e.g. API design that
> leads to many useless heap allocations/deallocations; calloc() followed by
> memcpy(), etc
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Rowan Tommins]

On 04/03/2021 00:37, Ben Ramsey wrote:

On Mar 3, 2021, at 14:25, Kamil Tekiela  wrote:

when both are strings then chances are that this is an error.


Except when comparing two values from sources known to provide numbers as 
strings, such as form input and database results. :-)



The juggling only makes a difference if the two sources provide 
different representations of the same number - "12345" is equal to 
"12345" whether you cast both sides to int or leave both as strings.


Regards,

--
Rowan Tommins
[IMSoP]

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