The next generation of C compilers is going to enforce the C standard
more strictly:
https://wiki.gentoo.org/wiki/Modern_C_porting
One warning that will soon become an error is -Wstrict-prototypes.
This is relatively easy to catch in most code (it will fail to
compile), but inside of autoconf tests it can go unnoticed because
many feature-test compilations fail by design. For example,
$ export CFLAGS="$CFLAGS -Werror=strict-prototypes"
$ ./configure
...
checking if iconv supports errno... no
configure: error: iconv does not support errno
(this is on a system where iconv *does* support errno). If errno
support were optional, that test would have "silently" disabled
it. The underlying issue here, from config.log, is
conftest.c:211:5: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
211 | int main() {
This commit goes through all of our autoconf tests, replacing main()
with main(void). Up to equivalent types and variable renamings, that's
one of the two valid signatures, and satisfies the compiler (gcc-12 in
this case).
Fixes GH-10751
1. Implementation based on https://github.com/WojciechMula/base64simd
2. Only runtime path is added to reduce the complexity of SIMD variants.
3. Expand test case to cover SIMD implementation.
Signed-off-by: Frank Du <frank.du@intel.com>
The release VMs already enforced this, but PHP's configure script did
not.
re2c 0.13.5, which timelib's date/time parser requires is no longer
compatible with the current version of Zend/zend_language_scanner.l, as
it starts spinning in a loop.
As with other SIMD-accelerated functions in php-src, the new UTF-16
encoding and decoding routines can be compiled either with AVX2
acceleration "always on", "always off", or else with runtime detection
of AVX2 support.
With the new UTF-16 decoder/encoder, conversion of extremely short
strings (as in several bytes) has the same performance as before,
and conversion of medium-length (~100 character) strings is about 65%
faster, but conversion of long (~10,000 character) strings is around
6 times faster.
Many other mbstring functions will also be faster now when handling
UTF-16; for example, mb_strlen is almost 3 times faster on medium
strings, and almost 9 times faster on long strings. (Why does mb_strlen
benefit more from AVX2 acceleration than mb_convert_encoding? It's
because mb_strlen only needs to decode, but not re-encode, the input
string, and the UTF-16 decoder benefits much more from SIMD
acceleration than the UTF-16 encoder.)
These are mandatory in C99, so it's a pointless waste of time to check
for them.
(Actually, the fixed-size integer types are not mandatory, but if they
are really not available on some theoretical system, PHP's fallbacks
won't work either, so nothing is gained from this check.)
The current behavior has been introduced 20 years ago in
f9e375f493 as part of a larger change.
It's not clear to me why special treatement of -lpthread is necessary
here.
Currently compiler flags passed by extensions using the standard
``PHP_NEW_EXTENSION`` and ``PHP_ADD_SOURCES`` m4 macros are prepended
before the ones defined by ``Zend/Zend.m4``.
This was not really an issue before as ``Zend.m4`` only included
``-Wall`` but since the addition of ``-Wextra`` various issue about
disabling flags have been brought up.
A preliminary attempt was done in commit 5c1cf7669b
but this turns out to be more or less irrelevant.
The root issue is that ``PHP_NEW_EXTENSION`` and ``PHP_ADD_SOURCES`` call the
``PHP_ADD_SOURCES_X`` macro and pass their flags as the 3rd argument which prepends
the flags. There exists a 6th argument for this macro which appends them but from a
cursory look at https://heap.space/search?full=PHP_ADD_SOURCES_X&project=php-src
this is not used. Moreover, the comment describing this macro explicitly informs
that this macro should not be used directly.
As such we drop the 6th argument of ``PHP_ADD_SOURCES_X`` and move the `special-flags`
argument to be appended instead of prepended.
Closes GH-6204
Given that this executes a random function with zero parameters,
actually executing the code doesn't make sense.
This should fix the imap + asan build.
Since libxml version 2.9.0 external entity loading is disabled by default.
Bumping the version requirement means that XML processing in PHP is no
longer vulnerable to XXE processing attacks by default.
