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.
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.
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.
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.
This is not necessarily useful for Windows (few use custom builds on
that platform), but for feature parity with other platforms it seems
reasonable to support it on Windows.
We make sure, though, that the feature is not enabled for snapshot
builds by adding the option to the build exclusions.
`PHP7DLLTS_EXPORTS` is not used throughout php-src, and it's unlikely
that it is used by any extension, especially since it still refers to
PHP 7. The symbol had been introduced in 2014[1], but is not even used
in latest PHP-7.4; probably it was just supposed to be used, or part of
phpng.
[1] <fc734cf95d>
Since CI already ran for the PR, we can now [skip ci].
"Since limited support for `/arch:AVX512` was added in Visual Studio
2017, and expanded in Visual Studio 2019"[1], we can safely offer this
option, since PHP 8.4 is supposed to build with Visual Studio 2022, and
it is unlikely that someone tries to build PHP 8.4 with Visual Studio,
requesting AVX-512 support.
[1] <https://learn.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-170>
Previously the CHECK_HEADER_ADD_INCLUDE function defined the
`HAVE_<header>_H` preprocessor macros to value 0 or 1 whether the
`<header.h>` file was found. This syncs it with Autotools build system
where most of these macros are either undefined or defined to 1.
In possible edge cases where such macros might be intentionally used
like this without being aware that HAVE_HEADER_H can be 0 or 1 on
Windows:
| #ifdef HAVE_HEADER_H
| ...
| #endif
there is backwards incompatibility for PECL extensions in case the
header wouldn't exist on Windows such code wouldn't execute. However,
this is considered a bug if such case is present. From the Autotools
point of view, the check is correct though and should be used with
ifdef/defined() checks.
Help text is also synced to Autotools style:
`Define to 1 if you have the <header.h> header file.`
* Remove php_win32_init_gettimeofday declaration
Follow-up of GH-15400 (25afbdb09e).
* Remove unused header include
* Include php.h before win32/ioutil.h
* Explicitly drop support for old clang versions on Windows
This ensures compatibility with the typedef redefinitions we use, and
makes it clear during the `configure` stage that old compiler versions
are not supported.
See <https://releases.llvm.org/> regarding the release history of clang.
We also remove support for two number versions of clang, since as of
LLVM 4.0.0 the project uses a three number versioning scheme; see
<https://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html>.
The function always returned 0, and the return values was never used,
so we declare it to return void.
While we're at it, we also fix the space indentation of the comment.
* GetSystemTimePreciseAsFileTime() is now always available
As of PHP 8.3.0, we require Windows Server 2012 or Windows 8 as bare
minimum. Since GetSystemTimePreciseAsFileTime() is always available on
these Windows versions[1], there is no more need for the workaround
described in dllmain.c; we just can call the function directly.
[1] <https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime>
From the documentation[1]:
| We're updating the Microsoft C++ preprocessor to improve standards
| conformance, fix longstanding bugs, and change some behaviors that
| are officially undefined. We've also added new diagnostics to warn
| on errors in macro definitions.
Thus it appears to be sensible to switch to the new preprocessor for
all VS17 builds. Note that although the new preprocessor is available
as of VS16.5 (i.e. `version >= 1925`), we don't want to potentially
break older builds, and as such use the new preprocessor only for VS17
builds. Users who wish to use the new preprocessor with VS16, can
still `set CFLAGS=/Zc:preprocessor` before running `buildconf`/`phpize`.
[1] <https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170>
Closes GH-15201.
- The ZTS is defined on only one place
- Added help text for ZTS preprocessor macro
- The 'enable_zts' variable replaced with PHP_THREAD_SAFETY in
configure.ac.
- Nits fixed.
Git can track executable (0755) and non-executable (0644) file modes.
This is a minor file permissions sync for the win32/build/mkico.sh
(0755).
[skip ci]
"Since limited support for `/arch:AVX512` was added in Visual Studio
2017, and expanded in Visual Studio 2019"[1], we can safely offer this
option, since PHP 8.4 is supposed to build with Visual Studio 2022, and
it is unlikely that someone tries to build PHP 8.4 with Visual Studio,
requesting AVX-512 support.
[1] <https://learn.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-170>
PR #13498 bumped the required OpenSSL version to 1.1.1, but apparently
only for non Windows system. We catch up somewhat by dropping support
for OpenSSL < 1.1.0 on Windows; besides completely removing detection
of old OpenSSL versions in `SETUP_OPENSSL`, we also ensure that all
bundled extension using this function do no longer accept OpenSSL <
1.1.0, to avoid to still be able to build these extensions with older
`phpize` scripts.
We do not cater to `--phar-native-ssl` yet; that might better be
addressed by #14578.
Closes GH-14973.
As of Visual Studio 2015, the major version of the compiler (`cl.exe`)
is 19, and the minor version increases by steps of 10. However, the
latest Visual Studio 2022 release has the version `19.40`, so that
Visual Studio version is not properly detected. This is not a big deal
regarding the reported compiler version (`php -v` etc.), but the
filenames of the builds would no longer match the expectations (instead
of `vs17` there is now `19.40.33811` or another build number). This
implies that the files would have to be renamed manually to be properly
handled by windows.php.net (or that code would have to be adapted).
Therefore we update the version detection to detect all versions < 1950
as Visual Studio 2022, assuming that "For major releases, the minor
version increases by 10."[1] still holds in the future.
[1] <https://learn.microsoft.com/en-us/cpp/overview/compiler-versions?view=msvc-170#visual-studio-2017-and-later>
The --no-generation-date flag is a common re2c flag used in all re2c
invocations. This adds the 2nd optional argument to PHP_PROG_RE2C M4
macro in BC manner to set the default re2c command-line options and sets
the default RE2C_FLAGS similarly on Windows.
This is not being synced with changes done in github.com/winlibs and
served only for documentation purposes. Since the list is outdated it is
simpler to remove it than maintain it updated.
This enables outputting additional debugging messages when running
phpdbg for developing and troubleshooting phpdbg itself. Option was
already added in Autotools and this adds it also to Windows build
system.
Because additional info is printed when running tests, the
--enable-phpdbg-debug option is excluded when building with
--enable-snapshot-build if not provided explicitly.
This syncs the HAVE_GRP_H definition on Windows (manually defined) and
Autotools (checked with AC_CHECK_HEADERS):
HAVE_GRP_H is is either undefined or defined to value 1.
