`__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.
* ext/soap: Add some SoapServer tests
* ext/soap: Don't call readfile() userland function
We can perform the operation directly, moreover there is no risk of a user disabling the readfile function and defining their own messing up what we are doing.
* ext/soap: Actually throw a SOAP Fault if the WSDL has disappeared
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/>
The code to update the call_level in that case skips the opline itself,
as that's handled by the tail handler, and then wants to set the opline
to the last opline of the block because the code below the switch will
update the call_level for that opline.
However, the test has a block with a single opline (THROW). The block
after that has ZEND_INIT_FCALL, because `i` points to ZEND_INIT_FCALL
now, it erroneously causes the call_level after the switch.
Closes GH-17438.
This is apparently not supported there; the VS supplied clang version
18.1.8, reports:
`clang-cl: warning: unknown argument ignored in clang-cl: '-fwrapv' [-Wunknown-argument]`
`GetProcAddress()` returns a `FARPROC` (aka. `long long (*)()`) which
is not compatible with `void *` per the specs. However, on Windows
they are, so we silence the warning with a cast.
The phpdbg issue is a real issue, although it's unlikely that harm can
be done due to stack alignment and little-endianess. The others seem
to be more cosmetic.
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>
As per the discussion in GH-17120, we are printing a placeholder value only.
The commit history of that PR also includes alternative implementations, should
a different decision be desirable.
Fixes GH-17096
Closes GH-17120
