These internal-only functions accepted a `php_random_status`, just to extract
the internal state from the `state` pointer. Make them take the state struct
directly to improve type safety.
bug#75721 patch from jonathan@tangential.ca.
MCAST_JOIN_GROUP/MCAST_LEAVE_GROUP socket option for the RFC 3678
support does not work on freebsd, using IP_ADD_MEMBERSHIP instead.
This syncs the installed sapi and extension headers on *nix and Windows
systems by installing only what is intended outside of php-src.
- ext/gd: without gd_arginfo.h and gd_compat.h
- ext/hash: php_hash_joaat.h and php_hash_fnv.h added also on Windows
installation; xxhash/xxhash.h added on both installations as it is
included in php_hash_xxhash.h; Include path for xxhash.h changed to
relative so the php_hash_xxhash.h can be included outside of php-src;
Redundant include flags removed
- ext/iconv: without iconv_arginfo.h
- ext/mysqli: mysqli_mysqlnd.h was missing on Windows
- ext/phar: php_phar.h was missing on Windows
- ext/sodium: php_libsodium.h was missing on *nix
- ext/xml: without xml_arginfo.h
- sapi/cli: cli.h was missing on Windows
Closes GH-13210
Closes GH-13213
libgd uses an incorrect absolute path check in gdft.c.
It checks if either the path starts with a '/' (only valid on Posix
btw), or whether it contains something of the form C:\ or C:/.
However, this overlooks the possibility of using UNC paths on Windows.
As we already do PHP-specific stuff with VCWD_ macros, use
IS_ABSOLUTE_PATH to check for an absolute path which will take into
account UNC paths as well.
Closes GH-13241.
The code currently assumes that the extra field length of the central
directory entry and the local entry are the same, but that's not the
case. For example, the "Extended Timestamp extra field" differs in size
for local vs central directory entries. This causes the file contents
offset to be incorrect because it is based on the central directory
length instead of the local entry length. Fix it by reading the local
entry and getting the size from there as well as checking consistency
for the file name length.
Closes GH-13045.
Add various tests showcasing the behavioural variations of different offset types used on various container types in all possible operations:
- Read
- Write
- Read Write
- Appending
- Unsetting
- Existence checks with isset()/empty/null coalesce operator
- Behaviour of nesting dimensions (e.g. $container[$offset1][$offset2])
Add a test to ensure compile time and runtime behaviour is identical for offsets.
Add an internal class that overloads the dimension object handlers to zend_test
When mbstring.encoding_translation=1, and PHP receives an (RFC1867)
form-based file upload, and the Content-Disposition HTTP header contains
a filename for the uploaded file, PHP will internally invoke mbstring
code to 1) try to auto-detect the text encoding of the filename, and if
that succeeds, 2) convert the filename to internal text encoding.
In such cases, the candidate text encodings which are considered during
"auto-detection" are those listed in the INI parameter
mbstring.http_input. Further, mbstring.http_input is one of the few
contexts where mbstring allows the magic string "pass" to appear in
place of an actual text encoding name.
Before mbstring's encoding auto-detection function was reimplemented,
the old implementation would never return "pass", even if "pass" was the
only candidate it was given to choose from. It is not clear if this was
intended by the original developers or not. This behavior was the result
of some rather subtle details of the implementation.
After mbstring's auto-detection function was reimplemented, if the new
implementation was given only one candidate to choose, and it was not
running in 'strict' mode, it would always return that candidate, even
if the candidate was the non-encoding "pass".
The upshot of all of this: Previously, if
mbstring.encoding_translation=1 and mbstring.http_input=pass, encoding
conversion of RFC1867 filenames would never be attempted. But after
the reimplementation, encoding 'conversion' would occur (uselessly).
Further, in December 2022, I reimplemented the relevant bit of
encoding conversion code. When doing this, I never bothered to
implement encoding/decoding routines for the non-encoding "pass",
because I thought that they would never be used. Well, in the one case
described above, those routines *would* have been used, had they
actually existed. Because they didn't exist, we get a nice NULL pointer
dereference and ensuing segfault instead.
Instead of 'fixing' this by adding encoding/decoding routines for the
non-encoding "pass", I have modified the function which the RFC1867
form-handling code invokes to auto-detect input encoding. This function
will never return "pass" now, just like the previous implementation.
Thanks to the GitHub user 'tstangner' for reporting this bug.
* Remove ext/imap — it has been moved to PECL
https://pecl.php.net/package/imap
* Remove files related to IMAP
* Remove IMAP CI files and set up
* Also disable IMAP on Circle CI
* Update CREDITS file
* Remove IMAP entry from CODEOWNERS
* Revert "Remove files related to IMAP"
This reverts commit a05ffd6c97.
* Mark IMAP is being removed
* Revert "Remove IMAP CI files and set up"
This reverts commit 82e5ba9910.
* Revert "Also disable IMAP on Circle CI"
This reverts commit e83827b0b2.
* Don't try to build imap extension with CI
* Restore test setup files
* Remove mention of imap in labeler, EXTENSIONS, and sample php.ini files
Previously, when an array was converted from packed to hashed, iterators would
not be correctly reset to 0. Similarly, removing the last element from an array
would decrease nNumUsed but not actually fix the iterator position, causing the
element to be skipped in the next iteration.
Some code was also removed that skips over IS_UNDEF elements for
nInternalPointer and iterator positions. This is unnecessary, as this already
happens during iteration.
Closes GH-13178
Closes GH-13188
When investigating another bug reported by GitHub user 'tstangner',
I discovered that PHP segfaults when the INI parameter
zend.script_encoding is set to "pass". This bug dates back to
December 2022 (caused by yours truly in 953864661a).
If any PHP users in the wild were actually setting zend.script_encoding
to "pass" (which would be an utterly useless thing to do), I expect that
someone would have filed a bug report by now. The absence of such bug
reports is evidence that nobody is doing this.
Hence, it seems that the best fix is simply to disallow "pass" as a
choice for zend.script_encoding. The internal function
'php_mb_zend_encoding_list_parser' which I am modifying to accomplish
this has no other in-tree callers, aside from the 'exif' extension.
Further, exif only calls the function with a few hard-coded values, and
none of them are the string "pass", so this change will not have any
impact on exif.
According to the docs, UNUM_ROUND_HALF_ODD is only available since ICU 69.0. The build on Travis currently fails probably because it uses a lower version.
* PHP-8.3:
Fix GH-13177: PHP 8.3.2: final private constructor not allowed when used in trait
Fix GH-12107: When running a stored procedure (that returns a result set) twice, PHP crashes
It needs to be "object".
This is because first- and third-party extension can register custom
node types using `php_libxml_register_export`. So we don't know upfront
what types can be expected.
This also changes the error to a TypeError everywhere.
The NumberFormatter::ROUND_HALFEVEN constant exists in PHP already, but its counterpart ROUND_HALFODD was missing.
This adds it, using `UNUM_ROUND_HALF_ODD`
Close GH-13191
The implementation of `php_random_uint128_*` exists specifically for
pcgoneseq128xslrr66 and takes up a third of php_random.h. Split it into its own
header to keep php_random.h focused on the functionality directly related to
randomness.
Tim Düsterhus