[PHP-DEV] PHP 8.0.0alpha1 is ready for testing

[Sara Golemon]

PHP 8.0.0alpha1 has just been released and can be downloaded from:
https://downloads.php.net/~pollita
Or use the git tag: php-8.0.0alpha1

Windows binaries are available at: https://windows.php.net/qa/

This is the first official release of the PHP 8 serial and includes an
incredible amount of work.
Please test it carefully, and report any bugs at https://bugs.php.net

8.0.0alpha2 should be expected in 2 weeks, i.e. on 9 Jul 2020.
Hash values and PGP signatures can be found below or at
https://gist.github.com/sgolemon/9b268eb2606cdc9664d77a77f9595540

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso

php-8.0.0alpha1.tar.gz
SHA256 hash:
dbc1df78f4b4bf758d796c0265b05500ab5e8d501543c5d7f42aeb67c9bbaa13
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLMQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgXhEACHhj72vnMzXA5hHHCqP9OHO68kIpsf7M3Z
T+FnAH0YcsCBwo3F7DYE46+gp6bbY8+L0glJYGqJ/ff+WpMX6bE8OzWwOZsfhn7j
pn4LC7FElO75He2CtJR03Mgta3ZTrK3eRyDqr8PFbCF4Gcywlbk/BNuGmERLYwqE
jgR/oEd5ExiF/R/5aWEviThZv5WkNGzVwd4m5pd7PKw0b5C5ujTlYbOB8JboSuOC
AOvfOV/jTjPfOQa4+aSNTPTcksJ6DcHOHjgDqurvjBs0PxH16aNDA0cesT9TYbw1
L16Bm/cpLXXJLT5Alpn+NzwwlZVR87p5AYGlzPTUfyDEM+NkJbw+84lF8o4ZokTb
mAJewjaQoKkKcU9zakz5FyGIpvbthawB2zW3IS/KAI8kqHsjoxVhCNtuWhH/6D4A
Zx6fGJR54gF8n3Zdm2pDKzki5fyTssC078loH1G0VcW1cPavPFSjRvc3chgurnGF
VTk+33nWQiOjDhXgD4F5PXP+g6eaWSz1jHjtO5yON2rMpd8Id63KFkV/tpu7CfAI
JLIYNu52YnNgntZhEHvJrhQEr71F+qMAMb1HMCSUO4f4Goofc+PudbsMs6wWmTBc
D7QZvKARBuAQfqAecUDOMh7zlE+Tdolph8X8TOWwSdmf8lVvN17c0vMoukzg6Zrk
1fhq2RZeqA==
=iL1M
-END PGP SIGNATURE-

php-8.0.0alpha1.tar.bz2
SHA256 hash:
06fb3beb67176a0e096cb7e89368aa2a0063c0a963bc69dad862895e2474f4ee
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgwND/9lUGNPQ333g0EXyisVd3ddYN04+fmSyIG6
3nWS4xvph7VYGBzHqbyxmriHC9GPWcF1dBbD24fXzxxCpOy46vmwdJ27n0sHtdDf
7U5ViK0JCe8w7rehO01D0ZuQHERxsOllCg03uur7fHjy6m5VZq73NI+/LxX8uDI6
WCNh5PSjpkgOWtTShlkcD/OUWiynXajsjemIb0pNPYn/zIPSP1IYiJn8ZsewBIjQ
fKFqvvkOEMAzADlzAtBOvdQAno9UnbJAvQ1QzP6DlD5S7IZDRhuqm/92hJcYBVel
Wtwr/oAqPJsj6azsC0O5tA2c4vgkh8xpLKKX55e46k0dB6KZH8JWrz8zyMPN5NQN
xeGy0P883xeZZBG7HoRCLbxxSZm8GtnlxHGdLMtf9h9Rtz0fk2GHcJdAqYz6XlIj
mDDBiWf99xm6ANeC9dbfdebNzr5E8vZF4WYBAPN8I5KMH2vMv35QZSbncnnyDwBf
CHJAac3b8bwi8kR4QZd4N9/BrnBkiMxA+B2AFb1L0aXvamVZiX/bryse2NVmqyyr
yP4jZGHiq8reNinYvBI/m4f58bt8X7mFhSBjHWVcoZpCaWH/UXg5nVwbS1aKe0SP
ahypoxiOo/N89jY3xoF0MPMseQlSvgx6+aQq9sYrDuPDpJRSvlRQ1kxH4UQQ7lFf
zJEUOLDDag==
=p6DW
-END PGP SIGNATURE-

php-8.0.0alpha1.tar.xz
SHA256 hash:
2ab527b3b96908b123271ee390ea01169effeb5027a7f85dbe4d0d37d7da1628
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAl7yOLcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhct7wD/9qvy4ZTIHegEIqBzJrUSHgTy4uFSu5onED
XP7BTeCmftE7eXN4XNE4YZlGsPt+sTaGNuTXygued84c7cr+panT6bg52261h5I4
6A6SQr5Xb8MGcoCxZ/V7h/64AGRi3bRZNyS43JjksHLwuW1gt3tH2vKMbccHc7OH
ON2H4gkdgKx1a5fKX9HH1QCTorIvGQq3mgvQMwTJ+yQaQMHd8OOUMmTN6fycVsg9
wCdA+ld0tSDa47lkMVIsqeyjNSup98OvOz7r4ctiVgwbU7HSGhPxgW+k0TcvpEgc
W1stWg+6c+YHJXIP8cH+Fn4ClCkIDJnvmeT+1MaCAhMZfvCScwGG25h50235mMRn
kvTaBRVT6uZpCUR+6HQ149gsvymJIuJDVHEqMAW7Q9s+gyvYpNhfbZ+RUUA6z2ck
CzMukaEJcFYHpZiRyG7TNrTY29DgKXE0rVZ1S2o4LLbTYzLHm5weEa1nVXFIs7H2
qT9GkH1APTAzGk7sYwxK3sx6MJqvlWYnaWjbAO7QiaVdMGXPQI1d1n6yqFVEYMKR
BxHu0p4Sm0SEsT0Isw7Alz/h1ptm8qwci72cmw+npUdFaeDdF6aQu1riR8v1olhU
5PZVjtF4FhJH2eiOy49DV7W2uSDvNw/MXu80sySWfznJFRXcqLppn/5dH3moN76V
g356aZ68EQ==
=0dr0
-END PGP SIGNATURE-

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

[Derick Rethans]

PHP 7.4.8RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.4.8RC1

Windows binaries are available at: 

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

Hash values and PGP signatures can be found below or at
.

7.4.8 should be expected in 2 weeks, i.e. on July 9th, 2020.

Thank you, and happy testing!

Regards,
Derick Rethans


php-7.4.8RC1.tar.gz
SHA256 hash: 1db19a7db8d3bbee0ad42307ee94cb5ca2c5086e40a0cdee58f2318c31920bf1
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl7xsYMACgkQkQ3rRvU+
oxLofhAA5A3LNqH9umaVTa4tphiEl8LMvpdInxLXFRiJiNDURRdaLlY7Gdu/4nWv
1AGYi2ejhfuCav+Wz28kxJEKAK8IuTdwe5rBF29khXBozOJCa7MuNP1pv58AmXLO
9/YJ7YaUCEynVr2GcX7iYheyoX+mf7vc1AqFr0w6MhJMx41PHc3kh8MKm5qUlOmz
ymP5+CDf5S1gdSD8ZyAdmHtoWKhsSETy2D4+LxdGY/HhrVrjm5t8IXcZox/B8f0x
n2drPv1wmM0tM1+qDMxLLxyvhG1mBmG8gM0udbOYOqqJPKKcjPzT6n/BhkeUuQBs
nAqXkvX5dbSfdEdnv1V6UCwMh3w6+vBQgkeo0xiafjOLIbUlIwMic626D1vbvZea
qHz45x5TFMOaVe1zl+odDDOUQ+59j5FG8iNzT3SA/gF9e+37tzw2JXyyIpd6QTf1
JDvsVqdCz03ZCJqf0n+OptFhu8NZ7cjEB+RAUOqcyLwh5rwZUPDOEn4IrCFFQd6d
Pfd331WUszqEFJAgrxxIMZbzCYWYl+74g6jd9fL1FDT4c0e5pn6CjltK17LhHRhE
SJtR5fCcDic58HxWWpfX6VR26wm7ubjnmDbG1kB8OPSRwjZaVRjjHQtP9NVy3sRv
lqODN5zCj5gKthFeyXCW3yceQvBgqlY7rlqJkGyWqtAJHUtL/yo=
=NvFH
-END PGP SIGNATURE-

php-7.4.8RC1.tar.bz2
SHA256 hash: fd54adbd7b8b1d14689f483b615dc16bbcdde913510532041ecd6428d833933b
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl7xsYcACgkQkQ3rRvU+
oxJDpw//dMU+F49PWGGhSzQW9WNVfpzPvrUpef20ibXjJg+yvQ9wVlKwyatXCFeT
5cpB8S+/VA4zRLdHcLPPsaM5aWJHhxxzEAmtoDfvaTAcVvzsYqFe/iecG4vAX7T7
PnQj6dvpAIldfhBoQoRBc0MN0r+FLU/rp15t27vSbL8SZBPs3QXxPWogoS7A5GQq
Qt1hCfPAxXgFVA5egUHIBTvl6iMprG3IN72rjDKnOhjZ/FSk8bv2Dl3k3uMm2b9X
sHKj3i/HJ/wNKpXN/aSva+iW0U2tm/RV31Z90AVXT8z4oL0DP4aDuyvIl7TLFaxJ
6xrBvFM41IsXcHg/Gx/LSzt2qJ4VQRMwUhqoTKCyRn2CuWDL3DI/o+eCqsGalZqQ
l6WApNjfNgG1krGCrrin8B1d8KBsyf1HNqp5r51y+KQb4XhxxMiUNcLobAQzbWBs
0hfocOql95F8J6oRBGi0uM3VJbgaf1mf/mxhOBuy74JG7Tm+YVtWTvIMCJs2eElL
ZNDORw4i4J7TkjIbSyknasw+rl0IRQZc911V9OmeRZUbunJoDy3Lkl+MHZBiE8go
arkyjP68JmHUBWGmPZ9HzoE7ngpYS8XYvgifzYyGsOhNFAH9b+6P15CsJMxgWfF4
YTVomjGMZpfh1unTaRXCTPcGArUCy72gdAzky5qxHdETQEiWrc8=
=cQvm
-END PGP SIGNATURE-

php-7.4.8RC1.tar.xz
SHA256 hash: be869940c79e772aebccb6f35119a7ed1f954e10875d2ec01276fca6e64461a9
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl7xsYcACgkQkQ3rRvU+
oxK6HxAA1EVHhnNJRHu/1J4BN0w5YKp7smLcaSwegUqpp/kPtijpaBMLHo7j/edW
wGvICn9OOCKx/yHw9ykSRsn4f24FLA7zAuux12aXPDcm/ogG7SiSru/r2WjUwzWH
clzdZZbzWcUYFyXK4kGwhX2toZtHM5df5oz2pe636DdHTJb0DD0ohsgbZo+/sHVt
CgbV5OMfWVI5PCQgGtg1tjuVX6mLnNRZMHApfA4OWp9ne7QaqAuy9w4i9MvyEahc
bplzWuXpxcgkMhrRckhisjoqmHvkVkgGhH5bhbbHNnB2/9wwK5X3Hy0gwi1fpbIi
d9vt2yzcAQAcDmtOeWA5fZkGhmX+LwsFEp48JJ+s8P6hNctqyGTyIPaoNfTgzwaH
Yfet6llj+fUdVWNI2dbnMSRaP1Z6VnyVO6jzGgU9O0kI/hOefEaDXf+TqhXSXT1b
NR5t0WsX+SJnhVb+1HkbbyAHN8onZkEuuMEdHVCmLEvlOKGt1rVYChJ6ZnGOhEeH
OnRmBwlslY5bSWNouNc/O9h0jpI0lVz8WMBL6qqHo14wizvRXp5MPOi2VQT+rmHc
Bt+iihVAkMjGp9dRellJcSriNREcUzu6TF02viUGJn+elfHf7zMwJtRes/q0GP/r
LhSVV43fXndOYl/QRKJeBN3xGSjrQn/YlK70J8zfdSxyd5aExwM=
=4qXu
-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][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[G. P. B.]

Hello internals,

As the two week discussion period has elapsed the vote is now open.

We did acknowledge the suggestion of dropping the token name from the error
message directly, but in our opinion this is an orthogonal change to the
one proposed, and has the risk of not landing in PHP 8.0.

The vote will close on the 9th of July.

https://wiki.php.net/rfc/rename-double-colon-token

Best regards

George P. Banyard

Re: [PHP-DEV] Making the hardcoded string length limit of Throwable->getTraceAsString() configurable

[tyson andre]

> > Why is there a 15 byte limit in the first place?
> 
> Presumably it might be so that multi-megabyte strings are not dumped
> to the console when printing out a stack trace. (Disclaimer: I have
> not touched the relevant code and am just guessing.)

It apparently dates back to 2003, when exception::getTraceAsString() was first 
added.
https://github.com/php/php-src/commit/c80eb4573f8cbc268463c7ec233b467bd9b36b0f#diff-16cc0fb22dbf90c4c465180255880ea0R167
Arguably, computers have more disk space and better processors.

The reasons I can think of to keep a low default limit:
- Syslogs might use udp for async logging, which has a limit of 4096 bytes or 
so, which hasn't changed
- Code might truncate before logging an exception, and shorter argument 
representations would allow logging more frames of the stack trace
- Code might log exceptions to disk during abnormal events (e.g. network 
outages), and too high of a default would fill up disks faster
- CLI apps might fill up the entire screen or terminal scrollback buffer with 
megabyte-long strings (e.g. `string $file_contents`)

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

Re: [PHP-DEV] [VOTE] Remove inappropriate inheritance signature checks on private methods

[Nikita Popov]

On Fri, Jun 19, 2020 at 1:30 PM Alexandru Pătrănescu 
wrote:

> On Fri, Jun 19, 2020 at 12:17 PM Nikita Popov 
> wrote:
> >
> > On Tue, Jun 16, 2020 at 11:19 AM Marco Pivetta 
> wrote:
> >
> > > Hey Nikita,
> > >
> > > On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov 
> > > wrote:
> > >
> > >> On Mon, Jun 15, 2020 at 10:43 PM Pedro Magalhães 
> wrote:
> > >>
> > >> > Hi internals,
> > >> >
> > >> > I have opened the vote on the "Remove inappropriate inheritance
> > >> signature
> > >> > checks on private methods" RFC. Which can be found here:
> > >> >
> > >> > https://wiki.php.net/rfc/inheritance_private_methods
> > >> >
> > >> > The voting period will end on 2020-06-29 22:00 UTC.
> > >> >
> > >> > Thanks to those who participated in the discussion and provided
> > >> feedback.
> > >> >
> > >>
> > >> Voting no on this one, for the reason I previously mentioned on the
> PR:
> > >> While the abstract and static parts of the RFC make sense, the final
> part
> > >> does not (to me). Changing the behavior of private final just removes
> > >> existing functionality, without any clear benefit that I can see.
> What is
> > >> the problem that change tries to solve?
> > >
> > >
> > > Possibly missing in the RFC, but a parent class declaring a new
> `private`
> > > symbol shouldn't affect `private` API in child classes that may be
> > > pre-existing: helps backwards compatibility.
> > >
> >
> > Right, and I totally agree with that part insofar as it concerns
> > static/abstract handling. However, "private final" in particular is not
> an
> > accidental addition in the base class, it's an explicit design decision
> to
> > forbid certain behaviors in child classes.
> >
> >  The original RFC could at least
> > >
> > >> make a consistency argument, but the final form, which converts an
> > >> existing
> > >> special case into an even more convoluted special case, can not. Why
> is
> > >> __construct() exempted, but __clone() for example isn't, even though
> > >> similar considerations apply to it?
> > >>
> > >
> > > While `private final function __construct()` prevents child classes
> from
> > > making the constructor open, or accessing it (important for abstract
> > > types), `protected final function __clone()` achieves the same without
> > > having to rely on the `private` visibility modifier (
> > > https://3v4l.org/psR5F, for example).
> > >
> > > It is true that cloning is then possible from within a subtype, which
> is
> > > indeed a bit of a problem: https://3v4l.org/qupHR
> > >
> > > Maybe the magic methods would indeed all need to respect `final`, and
> we
> > > haven't considered all scenarios?
> > >
> >
> > Or ... we could just not change this part of the behavior at all :) If we
> > acknowledge that this is definitely useful for constructors and possibly
> > useful for cloning, then maybe it is useful for other things as well? I
> > still haven't heard a reason *why* we would want to do this change (not
> the
> > general change, but specifically the "private final" one).
> >
> > This stuff really isn't super important to me, and I'd be happy to
> > sacrifice this functionality in the name of the greater good, but I
> > honestly don't understand what that greater good is in this case. It
> seems
> > like a strict loss in functionality.
> >
>
> From how I understood it, right now "private final" cannot possibly
> have a real world use-case for other cases except for __construct and
> possibly for other fixed named magic methods like __clone.
>
> Someone can use it in a parent class and a child class developed by
> someone would have a restriction on what private method it can use to
> do his own private stuff.
> In reality, that's easily circumvented by choosing a different private
> name but this RFC will allow the user to use his prefered name for the
> private method. That's mainly why it's useful from my point of view.
>

I agree that the "private final" concept is only useful for cases where the
engine assigns special meaning to the method name, and can see the
rationale for not allowing it on normal (non-magic) methods.

I've dropped my "no" vote on the RFC. I don't like the specific decision on
this particular aspect, but not enough to block the rest.

Regards,
Nikita

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

[Christoph M. Becker]

PHP 7.3.20RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.3.20RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system.
7.3.20 should be expected in 2 weeks, i.e. on July 9th 2020.

Hash values and PGP signatures can be found below or at
.

Thank you, and happy testing!

Regards,
Stanislav Malyshev & Christoph M. Becker

php-7.3.20RC1.tar.bz2
SHA256 hash:
981f2b7d425ffc0c8d3469a47f1809a03ff1df3102cc2c717d4165f28b624832
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl7xwPUMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2lL4QAI3szF1MT/a22KZ+YtABXR/R20764Tz+1n5EYDiI
jlDG+lioX+Q1480D/NddgNI80ovPz/gho8s+W2UiZE54zCct10c8sFGNQ42VEJpL
3hwmoM9hkm6ofRSmkqvsZHN6Bo2R0/cN0hth2ZfkmCBy6vqxUgr/pwZNGEwjY1Hn
kgWR7FV7GwF1DHaBKxPJ3DWw5pXHLZJb7Djtp7SOgIrVNw5pXWLt1T72Wmp7/855
IdLE5j34b39g/yi/3B/IiYh28TFG4zfZrQfyqyGUv/tc5ZlM8zq4cE/YqUQ+HrxU
Vsg6CyrR7/Bc7qP9BCJcPh+Q/yQE+4EiGTY4D7TASQs4HvADbHjRJMa2GO1YsbW8
jld3K8pjOTwwJN93fi2poM7kwZ4Hi//JOJPZwJfIzNgX044DccbGt0bfOfe4zNS8
zp1OfkYTA+fTbUE4zruwOgXyeTjWf/duVGMg8rr146uXefIjHkL6UHu1EG/IZgGY
sFyfQKEqUcjbYl9J/sgjqdswOi6Kj/7zezbqwHAVt4qJOwJ+AS58WLq/OPk/hmvU
80zcHrekkN9oQNknBfdIDUJHFrA42NytI9MXZ4SemfRkL7dbghfkmoAVz+yh13PP
pbwLGWNJ8K/QgV0ecI3D4KGJTopKEOzwzskcVKpf8CxIQnThkCeOZASTEY+RZlO4
5ih3
=gn6Y
-END PGP SIGNATURE-


php-7.3.20RC1.tar.gz
SHA256 hash:
320923226003aa432b14caca13d37b73d32add5a9a129b50afe6093e51684621
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl7xwQMMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2iUQP/3W6GyA7T09GpKL+c06qykX60EOl3AoYuIPSLloo
q5z2VScCfqPPz6L0cddZLQtRysXxrYodAmQBClIbPAUKx0CPxz66nLkQWA3qkRww
1KIn9NjywQFMXj/NK9Oow/rft1ng+c8CWZoz/WPQdH1iSQSL8HCz10t/6sXMejED
pLSgKlKJFTcC+2yjjNRSJbp6MW5IgDuM0vTkbe7BFWLl2W+cE3dDzlqEpKQvFr4a
0Qmy1no6t38OW/zkKoqQbGbtBXvja+gj52BB55LAurypzYtDJjoTK+EgTWzBhhTd
G7uIIDPtkfslYLP1lvqVgl/BLjM4JHe3EKz3SQfOLg9CDZEtZCUx/mo04c0s068U
M5IXYKC8IxnzsjcTEwHfsX46UuFnpk0E0YBgtNMMdQNkhgf487DJWkIJNil9w+8D
m9zzJDGzwIvvUb8iSJTHR2QcwrzkQRSuvmyYZRJGOFDYJBD+5LPrXNlaGyoV24TP
8AYnkZ0u/Job+aKX24YVr0GhuH3AdWgnlBcNPgi3Ui08MDqSti3aC1ff6ZUKqB+/
aTYyr5DKdAfXz9mfmd9hZpffH/Tpf4Ap+dz5yUU8zLowkM0y1y6/OhoWxoVZYUC3
tdrBvc7LbW3g2QSONI7L9d6o5aT9wkEKu5UmN0v95bXPSHYMgLFRavHx70KOHfQ+
ztv1
=cqV6
-END PGP SIGNATURE-


php-7.3.20RC1.tar.xz
SHA256 hash:
76ddbd28f6405a6959a474c57b9babf0c6e005289c617e8498bc6aa1cd8b3275
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl7xwQMMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2ugAP/je1pgR+Leu9sOKju0fDMPo5wooMXyXW5mkdVCKT
yrGUD84fnHL/YjHVuNn/FxIQQxXW3EnYLxkU4a8/ohabsmY6U+ncznSiQAdBxTmk
TTyrl/Lq5b7VpdhMg/quLrujB1GgrS2F5OQKQbPDBMsGkT0SD6/90Sy2eybh94Vr
obIYzZUTjeh7a8GuzYZXzVtMXYxjZbxsIP0ZfrvXyP+8hFZQ9vGK1K5hK5VBjRyG
Dhv8BK/6HBhyphQnwE0gWDFiMRCOz1tdTgYCsdZi4oXIgB2/ApECTpiV93au7Ofo
54M7+z9jk8vuBrZ9xwsMfvdod/ejli6tOx0F7tOD9/od/ad8vI1iWAV2AiE9Z2vE
Ni5P/hqblJJsXxFiK/v1v0BLxv0CCF+ItraNvPhGWMmLJejIWcppQi1S5jhaL+c0
bRdaFHucSSlpAzOwZ7b83USC96P7uJWBYnk+Lnu56mltEgAEcnp0JEbJp0zj4hUg
gGj4tL8dQKOW7uEXmnvt9CylHHkssJxeuZxwrqP2bsBRttVRDgJeJv6Pq/NE7vRA
rfkGR1CRAKVrfyWdMZrXq7LaulsYGAqcsKlwd/XIPKGsf9hQH/SYuCE8UvZ6E+L5
u76sCB8we2GAMEFapbJ0pfNJ2tiwI9zoy0ITyBl09ZpwjoPe7+fRVI1b1uEBQ1eL
A4k0
=hQzK
-END PGP SIGNATURE-

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

[PHP-DEV] PHP Bug #79714

[Henrik Skov]

Hi !

I recently submitted this bug:
https://bugs.php.net/bug.php?id=79714

I am writing to the list in the hope that I can find someone willing to 
look into it. I might be willing to pay money in order to get this bug 
fixed.


For a detailed description of the bug, please see the link above.

I have spent a couple of nights trying to solve the problem myself - 
However, my knowledge of the ZendEngine is very limited so the effort 
has been to no avail thus far.


Could anyone please look into this bug - or maybe just give me some 
pointers on how to proceed ?

I would be willing to help in any way possible.

Thus far, the problem seems to be "conflicting" zend_persistent_script 
*bcgen_compile_file(zend_file_handle *file_handle, int type) in
./ZendAccelerator.c 



vs

zend_op_array *phar_compile_file(zend_file_handle *file_handle, inttype) 
in /ext/phar/phar.c 



but for details - please see the bug.

Thanks in advance !

Best regards,

Henrik Skov
Secuno A/S
www.secuno.dk

Re: [PHP-DEV] Making the hardcoded string length limit of Throwable->getTraceAsString() configurable

[Thomas Lamy]

Am 24.06.20 um 21:22 schrieb tyson andre:

Hi internals,

By default, strings in parameter lists are truncated to 15 bytes by default in 
Throwable->getTraceAsString()
(and Throwable->__toString() as a consequence).
(in Zend/zend_exception.c in `static void _build_trace_args(zval *arg, 
smart_str *str)`)

This limit is too short to see relevant information such as file paths, full 
urls, etc, which makes reporting bugs in applications inconvenient.

Would there be any interest in an ini setting such as 
`exception_string_length_limit` as a non-negative value to raise this (either 
allowed to be 0 or more or 15 or more, defaulting to 15)

()

Thanks,
- Tyson


+1, wanted this for years but never got around to tackle it


Thomas

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

Re: [PHP-DEV] Making the hardcoded string length limit of Throwable->getTraceAsString() configurable

[Alex]

> Why is there a 15 byte limit in the first place?

Presumably it might be so that multi-megabyte strings are not dumped
to the console when printing out a stack trace. (Disclaimer: I have
not touched the relevant code and am just guessing.)

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