Peter Kokot [Tue, 9 Apr 2019 00:09:42 +0000 (02:09 +0200)]
Remove duplicated substitude for Makefile
The substitution is already done in the CLI's config.m4 file. Current
SAPIs only provide one PHP_EXECUTABLE variable, i.e. PHP CLI so the one
in the configure.ac can be removed.
Peter Kokot [Mon, 8 Apr 2019 21:39:45 +0000 (23:39 +0200)]
Remove HAVE_STRERROR
Checking for the strerror function presence is no longer needed since it
is part of the C89 standard [1] and can be safely assumed that all
current systems have it.
Check in the configure.ac and Windows defined symbol are still left
until the file library (libmagic) will be updated.
Added range options to the float validation filter
php_filter_int (called via the constant FILTER_VALIDATE_INT) has the options min_range
and max_range. they allow the user to not only test if a value is a double but also if
the value is inside a specific range. php_filter_float (called via the constant
FILTER_VALIDATE_FLOAT) didn't provide this yet, making validation of numeric but
not-only-int values more complicated for the user.
this commits implements the options min_range and max_range for the function
php_filter_float to fix this inconsistency.
Peter Kokot [Sun, 24 Feb 2019 09:21:25 +0000 (10:21 +0100)]
Remove checks for locale.h, setlocale, localeconv
The `<loccale.h>` header file, setlocale, and localeconv are part of the
standard C89 [1] and on current systems can be used unconditionally.
Since PHP 7.4 requires at least C89 or greater, the `HAVE_LOCALE_H`,
`HAVE_SETLOCALE`, and `HAVE_LOCALECONV` symbols defined by Autoconf in
configure.ac [2] can be ommitted and simplifed.
The bundled libmagic (file) has also been patched already in version
5.35 and up in upstream location so when it will be patched also in
php-src the check for locale.h header is still left in the configure.ac
and in windows headers definition file.
Peter Kokot [Sun, 7 Apr 2019 13:55:34 +0000 (15:55 +0200)]
Remove HAVE_SIGNAL_H
The `<signal.h>` header file is part of the standard C89 headers [1] and
on current systems can be included unconditionally.
Since file requires at least C89 or greater, the `HAVE_SIGNAL_H` symbol
defined by Autoconf in Zend.m4 [2] can be ommitted and simplifed.
The bundled libmagic (file) also ommits the usage of HAVE_SIGNAL_H since
5.35 however current version in PHP is very modified 5.34 version and
will be refactored separately. Check for HAVE_SIGNAL_H is therefore
still done in the configure.ac.
Peter Kokot [Sun, 7 Apr 2019 13:20:02 +0000 (15:20 +0200)]
Remove HAVE_LIMITS_H
The `<limits.h>` header file is part of the standard C89 headers [1]
and on current systems can be included unconditionally.
Since PHP requires at least C89 or greater, the `HAVE_LIMITS_H` symbol
defined by Autoconf in configure.ac [2] can be ommitted and simplifed
however due to bundled file library (libmagic) and timelib still using
it, the removal there was omitted and done only in Zend.m4 file.
Current bundled libraries libtime, oniguruma, and libmagic still include
partial `HAVE_LIMITS_H` usage and will be more refactored when this is
possible.
Peter Kokot [Tue, 19 Mar 2019 22:49:26 +0000 (23:49 +0100)]
Refactor AC_INIT in configure.ac and PHP versions
Since Autoconf 2.53 the AC_INIT call with only a single argument has
been made obsolete and now includes several other optional arguments to
make installation experience a bit better by providing program version
and links to the project in the `./configure -h` output. This patch also
updates win build version. The phpize.m4 AC_INIT has been updated with
the call without arguments.
Always use ZEND_SECURE_ZERO() when cleaning up data
Optimizing compilers have an annoying tendency to throw out
memsets over data that they think aren't used anymore. Apply secure
zero-out in cases where this has potential to happen.
Commit 6a624c1[1] mostly replaced `COMPILER_NAME` with
`COMPILER_NAME_LONG` and `COMPILER_NAME_SHORT`, but not all
occurrences, what broke the Clang ASAN configuration. We fix this by
getting rid of `COMPILER_NAME` altogether.
Anatol Belski [Sun, 31 Mar 2019 12:18:12 +0000 (14:18 +0200)]
Rework the VS version evaluation
For the latest versions, refer also to the Visual Studio version, not to
the exact toolset version. The latest Visual Studio versions are moving
fast and the method existed previously is not sutable to keep up
anymore. Instead of refering to the exact toolset, it refers to the
Visual Studio version and implies the latest toolset available there.
That is still not ideal, another situation can arise where VS version is
not changed, but the toolset version is. It might be better to refer to
it a generic way in the future or even omit at all, and improve the
internal compatibility checks instead.
Anatol Belski [Sun, 31 Mar 2019 12:01:36 +0000 (14:01 +0200)]
Implement stricter extension compatibility check
This hardens the dynamic module loading by checking the linker compatibility
between the core and the dynamic module. This likely should be extended
for the CRT as well, as 2015, 2017 and 2019 versions of Visual Studio
all have same DLL name for the CRT.
projects / php / log