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
This previously errored with:
win32\globals.c(66): error C2220: the following warning is treated as an error
win32\globals.c(66): warning C4013: 'php_win32_signal_ctrl_handler_request_shutdown' undefined; assuming extern returning int
This only errors on master because of 2473f57ba (thanks to Niels for
that info!).
Closes GH-18508
The ctrl_handler is never destroyed. We have to destroy it at request
end so we avoid leaking it and also avoid keeping a reference to
previous request memory in a next request. The latter can result in a
crash and can be demonstrated with this script and `--repeat 2`:
```php
class Test {
public function set() {
sapi_windows_set_ctrl_handler(self::cb(...));
}
public function cb() {
}
}
$test = new Test;
$test->set();
sleep(3);
```
When you hit CTRL+C in the second request you can crash.
This patch resolves both the leak and crash by destroying the
ctrl_handler after a request.
Closes GH-18231.
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.
sendmail.h is not only included by sendmail.c, but also by
php_win32_globals.h, because that header uses some of the defined
macros. However, the forward declarations of the static functions are
not needed anywhere else than in sendmail.c, and Clang warns about the
unused functions elsewhere (`-Wunused-function`). Thus we move the
forward declarations to sendmail.c.
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.
We prefer clean solutions (such as declaring the proper type in the
first place, or introducing a portable format specifier) where easily
possible, but resort to casts otherwise.
We also port f1480ab14b.
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.
`__forceinline` is MSVC specific (and also understood by Clang on
Windows), but the code in win32/ should not be constrained to these
compilers. Since we already have `zend_always_inline`, we use this
instead.
If `path_len` is zero, we must not access `path`, let alone try to
subtract `-1` from it.
Since `path` and `path_len` are supposed to come from a `zend_string`,
this is not a security issue.
Closes GH-17471.
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/>
We're considering making this used as a glob implementation on POSIX as
well, but first, we should rebase it from the latest version of OpenBSD.
This also adds a new internal header (charclass.h) for glob.
See conversation in GH-15564.
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
The original patch[1] cared only about pipe handles in the rset, but
would be problematic if there are other handles (e.g. files in the
rset, or pipes/files in the other sets), because `php_select()` would
return immediately, reporting all non read-pipe handles as ready, but
possibly never reporting read-pipe handles.
We fix this by applying different logic for the case where only pipe
handles are supplied in the rset, but no handles in the wset or eset.
In this case `php_select()` only returns when actually one of the
handles is ready, or when the timeout expires. To avoid busy looping
in this case, we sleep for a short amount of time. This matches POSIX
behavior.
In all other cases, `php_select()` behaves as before (i.e. prior to the
original fix), that is it returns immediately, reporting all handles as
ready.
We also add a test case that demonstrates multiplexing the output of a
couple of child processes.
See also the discussion on <https://github.com/php/php-src/pull/16917>.
[1] <b614b4a69a>
Closes GH-17174.
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>
