Checklist to confirm PHP 8.2 compatibility

[IMSoP]

Since PHP has a policy of avoid Breaking Changes in "minor" releases, the library should in theory be compatible with any PHP 8.x. In practice, each PHP release has a small number of breaking changes, which might require small adjustments. (Note that there will be a larger list of new Warnings and Deprecations, but fixing these is not essential to consider the library compatible.)

For PHP 8.2, the manual lists the following incompatible changes. Once we have checked all of them, it should be safe to consider the library "PHP 8.2 compatible".

• DateTime::createFromImmutable() now has a tentative return type of static, previously it was DateTime.
  • "Tentative return types" are a concept only introduced in PHP 8.1 (as a step towards a PHP 9.0 or later change); so this library won't care about them at all
• DateTimeImmutable::createFromMutable() now has a tentative return type of static, previously it was DateTimeImmutable.
  • As above
• number symbols in relative date formats no longer accept multiple signs, e.g. +-2.
  • Searching for "-+" and "+-" shows no relevant code. Seems very unlikely to be a problem.
• ODBC and PDO_ODBC
  • as far as I can see, the library doesn't directly support either of these extensions
• glob() now returns an empty array if all paths are restricted by open_basedir. Previously it returned false.
  • 9 uses of glob(); most already assume the result is an array
  • \Zend_Cache_Backend_File::_clean does explicitly check for false, but only to shortcut the function and avoid a foreach loop
• FilesystemIterator::__construct(): prior to PHP 8.2.0, FilesystemIterator::SKIP_DOTS constant was always set and couldn't be disabled.
  • No uses.
• strtolower(), strtoupper(), stristr(), stripos(), strripos(), lcfirst(), ucfirst(), ucwords(), and str_ireplace() are no longer locale-sensitive.
  • The library never sets the system locale; the only use of setlocale() is to fetch the current setting (setlocale(LC_ALL, 0))
• str_split() returns an empty array for an empty string now.
  • There are a bunch of uses of this. There is a slim chance that one of them was accidentally relying on this behaviour.
• ksort() and krsort() now do numeric string comparison under SORT_REGULAR using the standard PHP 8 rules now.
  • This seems to be about comparing mixed lists of strings and numbers.
  • There are a handful of uses of these functions in the library; it's unlikely any are affected, but we could look closely to be sure.
• var_export() no longer omits the leading backslash for exported classes, i.e. these are now fully qualified.
  • Non-debug uses are in bin/classmap_generator.php, library/Zend/CodeGenerator/Php/Parameter.php, library/Zend/Serializer/Adapter/PhpCode.php, and library/Zend/Config/Writer/Array.php
  • It's unlikely these will break with the extra backslash, but we could test each to be sure.
• GlobIterator now returns an empty array if all paths are restricted by open_basedir.
  • No uses.
• The following methods now enforce their signature: SplFileInfo::_bad_state_ex(); SplFileObject::getCsvControl(); SplFileObject::fflush(); SplFileObject::ftell(); SplFileObject::fgetc(); SplFileObject::fpassthru()
  • Class is referenced in library/Zend/File/PhpClassFile.php and library/Zend/File/ClassFileLocator.php but no use of the affected methods
• SplFileObject::hasChildren() now has a tentative return type of false, previously it was bool. SplFileObject::getChildren() now has a tentative return type of null, previously it was ?RecursiveIterator.
  • No uses of SplFileObject.

[IMSoP]

None of the uses of var_export makes any assumption about the exact shape of the output, only that it's valid PHP. If anything, the change will improve them, by outputting code that could be executed correctly in a namespaced context.

None of the uses of ksort or krsort seem to be making any strong assumptions about the order of data, except in the case of some which are using only numeric keys anyway.