When opcache is enabled, error handling is altered in the following ways:
* Errors emitted during compilation bypass the user-defined error handler
* Exceptions emitted during class linking are turned into fatal errors
Changes here make the behavior consistent regardless of opcache being enabled or
not:
* Errors emitted during compilation and class linking are always delayed and
handled after compilation or class linking. During handling, user-defined
error handlers are not bypassed. Fatal errors emitted during compilation or
class linking cause any delayed errors to be handled immediately (without
calling user-defined error handlers, as it would be unsafe).
* Exceptions thrown by user-defined error handlers when handling class linking
error are not promoted to fatal errors anymore and do not prevent linking.
Fixes GH-17422.
Closes GH-18541.
Closes GH-17627.
Co-authored-by: Tim Düsterhus <tim@bastelstu.be>
The intmax_t is a C99 standard type defined in `<stdint.h>` and widely
available on current platforms. On Windows they are available as of
Visual Studio 2013. Using it conditionally as in these occurrences is
not needed anymore.
The ptrdiff_t is a C89 standard type defined in `<stddef.h>` and widely
available on current platforms. Using it conditionally as in these
occurrences is not needed anymore.
The /d2FuncCache1 compile option is already added by
toolset_setup_common_cflags() in confutils.js to all targets.
ZEND_DVAL_TO_LVAL_CAST_OK was removed in
3725717de1.
PHP once had getlogin() emulation implemented on Windows. This isn't the
case anymore since 2006 (dc34d34230),
neither Windows has getlogin() function.
* Move glob to main/ from win32/
In preparation to make the Win32 reimplementation the standard
cross-platform one. Currently, it doesn't do that and just passes
through the original glob implementation. We could consider also having
an option to use the standard glob for systems that have a sufficient
one.
* Enable building with win32 glob on non-windows
Kind of broken. We're namespacing the function and struct, but not yet
the GLOB_* defines. There are a lot of places callers check if i.e.
NOMATCH is defined that would likely become redundant.
Currently it also has php_glob and #defines glob php_glob (etc.) - I
suspect doing the opposite and changing the callers would make more
sense, just doing MVP to geet it to build (even if it fails tests).
* Massive first pass at conversion to internal glob
Have not tested yet. the big things are:
- Should be invisible to userland PHP code.
- A lot of :%s/GLOB_/PHP_GLOB_/g; the diff can be noisy as a result,
especially in comments.
- Prefixes everything with PHP_ to avoid conflicts with system glob in
case it gets included transitively.
- A lot of weird shared definitions that were sprawled out to other
headers are now included in php_glob.h.
- A lot of (but not yet all cases) of HAVE_GLOB are removed, since we
can always fall back to php_glob.
- Using the system glob is not wired up yet; it'll need more shim
ifdefs for each flag type than just glob_t/glob/globfree defs.
* Fix inclusion of GLOB_ONLYDIR
This is a GNU extension, but we don't need to implement it, as the GNU
implementation is flawed enough that callers have to manually filter it
anyways; just provide a stub definition for the constant.
We could consideer implementing this properly later. For now, fixes the
basic glob constant tests.
* Remove HAVE_GLOBs
We now always have a glob implementation that works. HAVE_GLOB should
only be used to check if we have a system implementation, for if we
decide to wrap the system implementation instead.
* We don't need to care about being POSIXly correct for internal glob
* Check for reallocarray
Ideally temporary until GH-17433.
* Forgot to move this file from win32/ to main/
* Check for issetugid (BSD function)
* Allow using the system glob with --enable-system-glob
* Style fix after removing ifdef
* Remove empty case for system glob
On win64, xmm6-xmm15 are preserved registers, but the prologues and
epilogues of JITted code don't handle these. The issue occurs when
calling into the JIT code again via an internal handler
(like call_user_func). Therefore, we want to save/restore xmm registers
upon entering/leaving execute_ex. Since MSVC x64 does not support inline
assembly, we create an assembly wrapper around the real execute_ex
function.
The alternative is to always save/restore these xmm registers into the
fixed call frame, but this causes unnecessary overhead.
The same issue occurs for ARM64 platforms for floating point register
8 to 15. However, there we can use inline asm to fix this.
Closes GH-18352.
It seems like n === undefined must have worked on older versions of
jscript, but currently it just causes the insertion to silently fail.
This sets n to an empty string, allowing phpize to include the local
config.w32 files.
This selection of suppressed warnings is pretty arbitrary, and
apparently disabling it does not raise any more warning for whole
php-src (except for `-Wno-deprecated-declarations`). As such it
appears to be pretty useless, and it seems to be more appropriate to
let users select which warnings to suppress via manually set `CFLAGS`.
Since we already apply `/wd4996`[1] when building with MSVC, and there
are indeed plenty of deprecation warnings, for now, we apply
`-Wno-deprecated-declarations` for Clang builds unconditionally.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996>
Closes GH-17554.
On Windows, the cli and phpdbg SAPIs have variants (cli-win32 and
phpdbgs, respectively) which are build by default. However, the
variants share some files, what leads to duplicate build rules in the
generated Makefile. NMake throws warning U4004[1], but proceeds
happily, ignoring the second build rule. That means that different
flags for duplicate rules are ignored, hinting at a potential problem.
We solve this by introducing an additional (optional) argument to
`SAPI()` and `ADD_SOURCES()` which can be used to avoid such duplicate
build rules. It's left to the SAPI maintainers to make sure that
appropriate rules are created. We fix this for phpdbgs right away,
which currently couldn't be build without phpdbg due to the missing
define; we remove the unused `PHP_PHPDBG_EXPORTS` flag altogether.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/nmake-warning-u4004>
Closes GH-17545.
First, more recent versions of Clang do no longer have trailing info in
parentheses, so the detection would fail. Since we're not interested
in this information, we just ignore it.
Then we should not rely on Clang being installed in the default program
folder. Instead we look up where the first clang.exe can be found, and
assume that it is located in a bin/ folder in the installation path.
From there we construct the library path, which is
`lib\clang\<ver>\lib\windows` where `<ver>` is either the full version
(older Clang) or only the major version. Note that this is the case
for stand-alone LLVM installations as well as Visual Studio supplied
ones.
Finally, we clean up by improving the error messages, and removing the
duplicate clang version detection in `add_asan_opts()`.
While we're at it, we also apply a cosmetic improvement to avoid
(trailing) whitespace in the compiler name (e.g. shown by `-v`).
Clang supports `__builtin_expect()` at least as of 4.0.0, which is the
(theoretical) minimum required on Windows, so we define it
unconditionally. This also solves some macro redefinition warnings in
JIT-IR.
For Clang, we just need to define the respective macros, since these
built-ins are available in all supported Clang versions (>= 4.0.0,
currently)[1].
For MSVC (and possibly other compilers) we use the respective APIs of
intsafe.h[2] which are available as of Windows 7/Server 2008 R2.
This avoids the UB due to signed integer overflow that may happen with
our fallback implementations.
We also drop the superfluous SHORT_MAX definition from pdo_firebird.
This shouldn't be defined unconditionally, but since it is apparently
unused, we remove it altogether.
[1] <https://releases.llvm.org/4.0.0/tools/clang/docs/LanguageExtensions.html>
[2] <https://learn.microsoft.com/en-us/windows/win32/api/intsafe/>
On Windows, phpize happily builds configure even if there is no
config.w32, but running configure then error with "Must be run from the
root of the extension source". This is confusing.
We bring phpize's behavior on par with POSIX systems, where the missing
config.m4 is detected and reported right away.
phpize builds on Windows ignore the paths of extension sources, and
build all object files in the same folder. This can't work if there
are multiple source files with the same base name stored in separate
folders and registered as such (e.g. cls/worker.c and src/worker.c).
While extension authors can work around by avoiding duplicate base
names, they may not even be aware of the problem because on POSIX
systems, the object files are usually placed right besides the sources.
Thus we take the relative path (from `configure_module_dirname`) of the
source files into account even for phpize builds. Since this may break
some extension builds (especially those which use Makefile fragments),
we do not apply this fix to stable branches.
Closes GH-17016.
Besides that is generally good practice to avoid macro redefinitions
(and symbol redeclarations), and we're doing this on POSIX platforms
anyway, there is a particular issue regarding phpize builds, where
config.w32.h actually includes config.pickle.h. The latter overrides
some macro definitions (e.g. `PHP_BUILD_SYSTEM`) to define the proper
values, but if config.w32.h is included multiple times, different macro
definitions eventually raise C4005 compiler warnings[1], which break
builds with `/WX /W1` enabled.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4005>
As is, whenever `proc_open()` needs to invoke the shell, cmd.exe is
looked up in the usual executable search path. That implies that any
cmd.exe which is placed in the current working directory (which is not
necessarily what is reported by `getcwd()` for ZTS builds), will be
used. This is a known attack vector, and Microsoft recommends to
always use the fully qualified path to cmd.exe.
To prevent any cmd.exe in the current working directory to be used, but
to still allow users to use a drop in replacement for cmd.exe, we
search only the `PATH` for cmd.exe (and pass the fully qualified path
to `CreateProcessW`), instead of relying on automatic executable search
by passing the base name only.
To be able to easily test this, we provide a minimalist C file which
will be build as test_helper, and used by the new test case.
[1] <https://msrc.microsoft.com/blog/2014/04/ms14-019-fixing-a-binary-hijacking-via-cmd-or-bat-file/>
Closes GH-17043.
While it is already possible to enable ASan for MSVC (assuming Visual
Studio 2019 16.10 or later) by passing `/fsanitizer=address` in the
`CFLAGS`, it is only usable if `ZEND_DEBUG` is also enabled; otherwise
there are `STATUS_BACK_STACK` errors all the time.
Since it makes some sense to combine ASan instrumentation with debug
assertions enabled anyway (typical for fuzzing), we support the
configure option `--enable-sanitizer`, which is already supported for
Clang builds, also for MSVC builds. Note that MSVC supports only ASan
for now; contrary to Clang which additionally supports UBSan on Windows.
Since ASan reports can be pretty useless without debug symbol
information, we require such builds to also produce PDBs (i.e.
`--enable-debug-pack`), but forbid actual debug builds (for performance
reasons, and because the way it is implemented it would not make sense;
that was already an issue with Clang builds with sanitizers enabled).
Closes GH-16999.
Note that this function is similar to `SETUP_OPENSSL`, but since the
zlib headers are not necessarily required, we append `_LIB`.
We are also more liberal regarding zlib(_a).lib, because
extensions requiring zlib are looking only for zlib.lib if ext/zlib has
been built as shared extension. This is overly restrictive at best,
and actually makes no sense, since (a) we're not shipping shared zlib
builds for years, and (b) users could have a zlib.lib which is a static
build (they could even just rename zlib_a.lib to zlib.lib).
* Don't fiddle with NDEBUG in C code
It is way to late to do this in php.h, since assert.h has already been
included. Even pushing that down to zend_portability.h may not have
the desired effect. Instead we define or undefine NDEBUG as CFLAG, so
that it works in all circumstances.
As a last resort we fail at build time, if `NDEBUG` is defined when
`ZEND_DEBUG` is enabled.
We also remove the useless workaround in zend_test to include assert.h
again, since that usually won't have any effect anyway.
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
While these "macros" work perfectly fine in confutils, it is somewhat
strange to have these two there, while all others are in config.w32
files.
In particular, there is no need for a `MODE_PHPIZE` guard, since there
are already config.w32 and config.w32.phpize.in.
However, we need to replace the semicolon in the helptext, because the
regex which parses ARG_(ENABLE|WITH) calls is restricted, and does not
accept semicolons.
`buildconf` (and `phpize`) have special treatment for these "macros".
When configure.js is built, all config.w32 are grepped, these "macros"
are appended to configure.js, and all config.w32 contents are appended
with the "macros" commented out. That means that for `configure` they
are in the toplevel anyway, so having them inside of `if` statements in
config.w32 is confusing.
Note that this matches autoconf behavior.
Whether we link with a debug runtime or a normal runtime is not really
related to `PHP_DEBUG`, but rather to `_DEBUG`[1].
We also stop defining that flag, since the compiler already does that.
[1] <https://learn.microsoft.com/en-us/cpp/c-runtime-library/debug>
This function is only available as of Windows 8 and Windows Server 2012,
respectively, and thus needed a fallback (albeit a non working one).
However, as of PHP 8.3.0 Windows 8/Server 2012 is required anyway, so
we can drop the fallback as well as the dynamic loading in favor of
linking to the import library.
For `phpize` builds, all three version variables are numbers, but for
`buildconf` builds, all are strings. This can yield surprising results
when extensions create their `PHP_VERSION_ID` like
10000 * PHP_VERSION + 100 * PHP_MINOR_VERSION + PHP_RELEASE_VERSION
Since `phpize` builds are way more common for external extensions
nowadays, we change the types for `buildconf` builds.
Closes GH-16247.
The dl_test extension is not supposed to be loaded via php.ini
settings, so we exclude it from the typical case on Windows where
`--enable-test-ini` is enabled by `--enable-snapshot-build`.
First we refactor to have only a single usage of `PHP_GAI_STRERROR()`
left; then we drop the macro in favor of calling the different
functions conditionally in an ad-hoc style.
This is necessary because the return value of `php_win32_error_to_msg`
needs to be freed by the caller.
The error messages are no more inline with other error messages, since
`gai_strerror()` apparently always appends a period and a space.
We also properly configure IPv4/v6 on Windows. Since WSPiApi.h has been
created in 2000, so we can safely assume that it is available everywhere
nowadays. Furthermore, `gai_strerror()` is available regardless of
whether there is IPv6 support.
