[pull] develop from boostorg:develop #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
windows-latest was moved to windows-2022 which does not have VS 2019
Also add test of this in combination with WIN32_LEAN_AND_MEAN. Checks for missing includes, such as shellapi.h
CommandLineToArgvW is defined in shellapi.h not windows.h although the former is usually included by the latter unless e.g. WIN32_LEAN_AND_MEAN is defined.
Add missing include: shellapi.h
windows-latest was moved to windows-2022 which does not have VS 2019
Undefining __STRICT_ANSI__ to enable GNU extensions is no longer allowed. As on Cygwin the native/standard functions are used, we don't need the wide-API extension functions. Only remaining extensions used are the stdlib.h setenv functions, so enable those via the macro _GNU_SOURCE
Undefining __STRICT_ANSI__ is no longer supported and is only required for the MinGW compilers, not the MinGW-w64 ones
Same as for the posix_stat_t: Ensure that the definitions of that struct hasn't changed between compiling and using the library.
Improve compatibility for recent MinGW-w64 and Cygwin compilers
Output random seed and progress indicator to be able to reproduce failures
Mention `setlocale` to use an UTF-8 codepage on Windows. Refer to `u8path` and `u8string` functions for std::filesystem::path
Help to debug random timeouts on Appveyor
The cin emulation in the test fails on this image.
Combine the with and without Boost.Filesystem cases into 1 test
Based on code reported at #150
Some modes seem to be incompatible with certain CI environments, e.g. newer Appveyor images making test fail sometimes. Set a known "good" mode to avoid this.
This enables e.g. the std::filesystem::path traits test
Creating console input events fails sporadically on recent Appveyor images when using CMake/CTest. Add an option to disable that and use it for the recent Appveyor image
It incorrectly returned 0 instead of -1
Find missing defines especially in standalone mode. See #152
To avoid that the standalong config.hpp becomes outdated, missing defines etc., the standalone/config.hpp is repurposed as a replacement for <boost/config.hpp> and basically pasted where that would be included in the nowide/config.hpp. Fixes the missing define as reported in #152.
Fix a few typos
Homebrew fails to build CCache as the OS seems to be too old
Use the GHA action with a provided token
GHA: Update to macos-12 and improve coverage upload
The following updates are performed: * update actions/cache to v4 * update actions/checkout to v4
Update GitHub Actions CI
Avoid errors like > /__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node) when using Ubuntu 16/18 containers with the @v4 actions See actions/checkout#1590
The VS 2019 image doesn't has Boost 1.77 anymore
macos-12 will be dropped by the end of 2024 so test with the newer versions already
buffering may be independent of tied streams, so make it an extra param
Download an unofficial Node 20 build against glibc 2.17
In order to return a non-owning pointer without memory leaks the function needs to use a static variable. When calling it from multiple threads there is a data race during the assignment (and conversion) to this variable. Fix by making it `thread_local`. Fixes #189
Using `bash` puts `/mingw64/bin` first in the path but the compiler from `/c/mingw64/bin` is used. This leads to errors running the tests: "Exit code 0xc0000139" (DLL issue) which are related to the use of `thread_local`. Using the powershell works in all cases.
There is a bug in GCC for 32bit MinGW until version 11. This causes a use-after free for destruction of `thread_local` variables that crash the application when the destructor accesses any member. In the tests it shows up as exit code/status `-1073741819` i.e. `0xC0000005`. Workaround this by not destructing the `stackstring` instance used to hold the value of the last `getenv` result. In the case where any call to `getenv` of a thread yielded a large value heap memory will be allocated and not freed due to this missing destructor call causing a memory leak, possibly for each thread. However values up to some length are stored on stack memory and hence the missing destructor call does not cause a memory leak as the type is essentially trivial in this state. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 Fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2
Make `getenv` thread-safe
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )