Function strftime is part of the C89 standard [1] and current systems
don't need to check for its presence anymore.
Additionally, checks for strftime function in tests have been removed
since the PHP strftime function is now always available.
1: https://port70.net/~nsz/c/c89/c89-draft.html
Previously zend_parse_parameters (and FastZPP) would handle invalid
arguments depending on strict_types: With strict_types=1, a TypeError
is thrown, with strict_types=0 a warning is thrown and (usually) NULL
is returned. Additionally, some functions (constructors always and
other methods sometimes) opt-it to throwing regardless of strict_types.
This commit changes zpp to always generate a TypeError exception in
PHP 8.
Changes:
- PHP_TM_GMTOFF removed
- HAVE_TM_GMTOFF replaced with HAVE_STRUCT_TM_TM_GMTOFF
- HAVE_TM_ZONE replaced with HAVE_STRUCT_TM_TM_ZONE
- HAVE_TZNAME removed
The PHP_TM_GMTOFF macro can be replaced with Autoconf's AC_CHECK_MEMBERS
that defines the HAVE_STRUCT_TM_TM_GMTOFF symbol instead of the
HAVE_TM_ZONE.
The HAVE_TZNAME symbol is not used in current code. The obsolete
HAVE_TM_ZONE symbol has been replaced with more proper
HAVE_STRUCT_TM_TM_ZONE. These are defined by the AC_STRUCT_TIMEZONE
macro.
The ext/date/lib is bundled library and also includes additional
timelib.m4 macros and checks specific for PHP.
All the checks in the timelib.m4 are already done in the PHP's
configure.ac:
- headers except for io.h and strings.h
- two functions checked strftime and gettimeofday
- if size of longint is 8
- if size of int is 4
- int32_t and uint32_t types using the PHP_CHECK_STDINT_TYPES
Macro `AC_TIMELIB_C_BIGENDIAN` defined in timelib.m4 is not used.
The two checkings for strtoll and atoll have been moved to date extension's
config0.m4 file.
Additional check for headers <io.h> and <strings.h> has been added to
config0.m4 of the date extension.
Therefore the timelib.m4 can be simplified and removed from the bundled
library to have easier maintenance in the later branches and also
upstream library.
get_properties() constructs these as fresh objects with no relation
to the internals, there is no need to clone them again. Additionally
the current implementation leaks memory, because the original objects
are never freed (see PR #3121).
Nikita Popov