delta/php-git.git, branch php-7.3.15 git.php.net: repository/php-src.git Fix # 79171: heap-buffer-overflow in phar_extract_file 2020-02-18T08:13:40+00:00 Christoph M. Becker cmbecker69@gmx.de 2020-01-26T15:03:35+00:00 254a7c245773d0dd16ead79a598f415dd0d6ee92 We must not access memory outside of the allocated buffer. (cherry picked from commit 7df594b9437aa4f127581e4c88da99e7c41a9b14) 
We must not access memory outside of the allocated buffer.

(cherry picked from commit 7df594b9437aa4f127581e4c88da99e7c41a9b14)
Fix bug #79221 - Null Pointer Dereference in PHP Session Upload Progress 2020-02-18T08:12:51+00:00 Stanislav Malyshev stas@php.net 2020-02-16T04:52:19+00:00 08b47a3d0fcd16a4a8f351d5ee60bfa64e71b39f (cherry picked from commit 409965fe1cfa013abd377a5b567e2d19aac163e8) 
(cherry picked from commit 409965fe1cfa013abd377a5b567e2d19aac163e8)
Fix bug #79082 - Files added to tar with Phar::buildFromIterator have all-access permissions 2020-02-18T08:12:09+00:00 Stanislav Malyshev stas@php.net 2020-02-16T06:17:14+00:00 2589f5bd83ff644d8345bb9c684fc4338435a3a3 (cherry picked from commit 6facfa59a5273a7084fabe13f215bb17215218c4) 
(cherry picked from commit 6facfa59a5273a7084fabe13f215bb17215218c4)
Bump version 2020-02-18T08:11:16+00:00 Christoph M. Becker cmbecker69@gmx.de 2020-02-18T08:11:16+00:00 a64d111c6ee64abd4dd1dd5d372b9c1871a2df1c 






Bump version
2020-02-04T10:53:59+00:00

Christoph M. Becker
cmbecker69@gmx.de

2020-02-04T10:53:59+00:00

41f46742576f3fa48e323f5571bee6db8e170249












Fix #78090: bug45161.phpt takes forever to finish
2020-02-03T23:44:04+00:00

Christoph M. Becker
cmbecker69@gmx.de

2020-02-03T10:47:01+00:00

079905acd536e772241def9ad098d16f45ef37d8

Not all systems support the discard protocol (TCP port 9), and since
there is no particular reason to use it, we switch to using actual
server testing.





Not all systems support the discard protocol (TCP port 9), and since
there is no particular reason to use it, we switch to using actual
server testing.







Fix #79191: Error in SoapClient ctor disables DOMDocument::save()
2020-02-03T22:31:46+00:00

Christoph M. Becker
cmbecker69@gmx.de

2020-02-03T22:10:20+00:00

fe1bfb78d65d28dd151da417477a0cee51de8afb

The culprit is the too restrictive fix for bug #71536, which prevents
`php_libxml_streams_IO_write()` from properly executing when unclean
shutdown is flagged.  A *more* suitable solution is to move the
`xmlwriter_free_resource_ptr()` call from the `free_obj` handler to an
added `dtor_obj` handler, to avoid to write to a closed stream in case
of late object freeing.  This makes the `EG(active)` guard superfluous.

We also fix bug79029.phpt which has to use different variables for the
three parts to actually check the original shutdown issue.

Thanks to bwoebi and daverandom for helping to investigate this issue.





The culprit is the too restrictive fix for bug #71536, which prevents
`php_libxml_streams_IO_write()` from properly executing when unclean
shutdown is flagged.  A *more* suitable solution is to move the
`xmlwriter_free_resource_ptr()` call from the `free_obj` handler to an
added `dtor_obj` handler, to avoid to write to a closed stream in case
of late object freeing.  This makes the `EG(active)` guard superfluous.

We also fix bug79029.phpt which has to use different variables for the
three parts to actually check the original shutdown issue.

Thanks to bwoebi and daverandom for helping to investigate this issue.







Relax test expectation
2020-02-03T12:03:54+00:00

Christoph M. Becker
cmbecker69@gmx.de

2020-02-03T12:02:12+00:00

b93e4aa11c409ae34c9088ba976117438fc80b9c

Since we're dealing with floating point numbers, precision issues may
hit us, and actually it's not necessary to check for the exact number
anyway, because it is not exact in the first place.  Therefore, we
relax the test expectations.





Since we're dealing with floating point numbers, precision issues may
hit us, and actually it's not necessary to check for the exact number
anyway, because it is not exact in the first place.  Therefore, we
relax the test expectations.







Fix #79212: NumberFormatter::format() may detect wrong type
2020-02-03T11:28:32+00:00

Christoph M. Becker
cmbecker69@gmx.de

2020-02-02T12:38:34+00:00

c2935499b14ee605452016ea00f3c0a94c0a1943

We have to convert to number *before* detecting the type, to cater to
internal objects implementing `cast_object`.

We also get rid of the fallback behavior of using `FORMAT_TYPE_INT32`,
because that can no longer happen; after `convert_scalar_to_number_ex`
the type is either `IS_LONG` or `IS_DOUBLE`.  We cater explicitly to
the `IS_ARRAY` case what also avoids triggering a type confusion when
`::TYPE_INT64` is passed as `$type`.





We have to convert to number *before* detecting the type, to cater to
internal objects implementing `cast_object`.

We also get rid of the fallback behavior of using `FORMAT_TYPE_INT32`,
because that can no longer happen; after `convert_scalar_to_number_ex`
the type is either `IS_LONG` or `IS_DOUBLE`.  We cater explicitly to
the `IS_ARRAY` case what also avoids triggering a type confusion when
`::TYPE_INT64` is passed as `$type`.







Fix bug #76047
2020-01-31T09:26:40+00:00

Nikita Popov
nikita.ppv@gmail.com

2020-01-31T09:21:37+00:00

ef1e4891b47949c8dc0f9482eef9454a0ecdfa1d

Unlink the current stack frame before freeing CVs or extra args.
This means it will no longer show up in back traces that are
generated during CV destruction.

We already did this prior to destructing the object/closure,
presumably for the same reason.





Unlink the current stack frame before freeing CVs or extra args.
This means it will no longer show up in back traces that are
generated during CV destruction.

We already did this prior to destructing the object/closure,
presumably for the same reason.