Fall back to -std=c++2a on compilers without -std=c++20 by bernardladenthin · Pull Request #105 · sheredom/subprocess.h

bernardladenthin · 2026-08-01T14:56:04Z

Problem

test/CMakeLists.txt compiles test20.cpp with a hardcoded -std=c++20. GCC 8 — still
the system compiler on RHEL 8 and its rebuilds — only implements C++20 under the
pre-release spelling and rejects the flag outright:

g++-8: error: unrecognized command line option '-std=c++20'; did you mean '-std=c++2a'?

The test suite therefore cannot be built with it at all, although the library itself
compiles fine.

Fix

Probe the flag instead of the CMake feature. CMAKE_CXX_COMPILE_FEATURES lists
cxx_std_20 on GCC 8, because CMake maps that feature onto -std=c++2a — so the feature
list cannot tell us which spelling the compiler accepts. check_cxx_compiler_flag can,
and -std=c++2a is used where -std=c++20 is unknown.

This keeps test20.cpp a real C++20 translation unit on those compilers, rather than
silently falling back to the default standard.

Testing

Ubuntu 20.04 (glibc 2.31, so the library builds there regardless of #104), with g++-8
8.4.0:

	Result
before	build fails at `test20.cpp`: `unrecognized command line option '-std=c++20'`
after	432 pass

Regression checks, all unchanged:

Compiler	Environment	Result
GCC 13.3	Ubuntu 24.04	432 pass
clang 18.1	Ubuntu 24.04	432 pass
MSVC 19.44	Windows, Ninja	387 pass

On MSVC the probe correctly reports failure — cl.exe only warns (D9002: ignoring unknown option), but CMake's built-in fail patterns catch that. The -std=c++2a
fallback is then discarded anyway, because subprocess_set_cxx_flags skips the standard
flag whenever SUBPROCESS_CXX_USE_STD_FLAG is false.

GCC 8 implements C++20 under the pre-release spelling only. CMake still lists cxx_std_20 as supported there because it maps the feature onto -std=c++2a, so the feature list cannot tell us which spelling the compiler accepts. Probe the flag itself instead.

sheredom#105 added -std=c++2a for GCC 8 and clang 9, which do not know -std=c++20. GCC 7 and older know neither, so the fallback passed a flag those compilers reject and the build stopped before running anything. NetBSD 9.4 ships GCC 7.5.0 and hit exactly this. test20.cpp now drops the standard flag when neither spelling is available, which is what already happens for test11.c without c_std_11 and for MSVC, where no -std flag is passed at all. The suite then runs that translation unit at the compiler default rather than not at all. Measured in GCC 7.5.0: -std=c++20 and -std=c++2a are both rejected, and the file compiles clean at the default gnu++14 under the flags CMakeLists sets. GCC 13 still selects -std=c++20 and the suite stays at 444/444.

* Add a portability workflow beside the existing matrix cmake.yml covers x86-64 Linux, Windows and macOS across four build types and four compilers, and it covers them well. What it cannot reach is anything that is not selected by the runner it happens to be on: the capability probes only ever resolve one way per machine, every runner is 64-bit, and no BSD or non-x86 architecture is present at all. The new workflow adds one job per dimension: capability-paths force each combination of SUBPROCESS_HAVE_CWD, SUBPROCESS_SPAWN_REPORTS_EXEC_ERRORS and SUBPROCESS_SPAWN_VIA_FORK on an ordinary runner linux-32-bit, windows-x86 ILP32, where uint64_t becomes unsigned long long musl a second libc foreign-arch ppc64le, riscv64, s390x, armv7 under qemu-user bsd real FreeBSD, NetBSD 9.4 and 10.1, OpenBSD VMs macos-deployment-target 10.14, 10.15 and 11.0, either side of the boundary that SUBPROCESS_HAVE_CWD turns on capability-paths is the cheapest and catches the most. The library selects its implementation at compile time, so on any given runner the other paths are never executed — including the ones added by #104 and #106, which as far as I can tell had never actually run anywhere before, only compiled. NetBSD is listed at both 9.4 and 10.1 on purpose: posix_spawn_file_actions_addchdir arrived in 10.0 and is spelled without the _np suffix, so the two take different paths through the header. foreign-arch runs under qemu-user, which is faithful for instruction-set semantics but not for posix_spawn's exec-error reporting — it does not propagate the errno, and a create_ex failure there would be an artifact rather than a platform property. That is noted in the file so nobody reads it the wrong way. * Narrow the emulated-architecture jobs to what emulation reproduces The first run of this workflow failed all four foreign-arch jobs, and for a reason that has nothing to do with the architectures: qemu-user does not propagate the errno that glibc's posix_spawn uses to report a failed exec, so create_ex_subprocess_create_failure_preserves_error fails there regardless of the target. s390x failed identically to ppc64le despite having no architectural difference in play, which is what gives it away. Running the whole suite under emulation therefore cannot go green, and a job that is permanently red is worse than no job. These now build the whole suite — which still covers compilation for each architecture — and run only the tests whose outcome actually depends on the instruction set: ./subprocess_test '--filter=*divzero' That is the reason the jobs exist: integer division by zero traps on x86, Arm and s390x but not on PowerPC or RISC-V. The comment explains the narrowing so it does not read as suppressing inconvenient failures. Also noted in the file that the SUBPROCESS_SPAWN_VIA_FORK combination in capability-paths is a no-op until #112 lands, so its green tick is not mistaken for evidence today. * Trim the workflow comments to what the YAML does not already say Reviewer feedback on #113: the file carried explanatory prose that repeated what the job and matrix names state. The paragraphs above capability-paths, linux-32-bit, musl and macos-deployment-target are gone entirely — "no chdir file action, no exec error reporting" and "macOS deployment target 10.14" already say it. Two survive as single lines, both where deleting the comment would invite a wrong edit rather than merely lose background: foreign-arch why it runs only *divzero. Without it the narrowing looks like an oversight and the obvious "fix" is a permanently red job. bsd why NetBSD is listed twice, so the duplicate does not get tidied away and take the 9.x path with it. The note that SUBPROCESS_SPAWN_VIA_FORK is a no-op until #112 lands is dropped as well. It was accurate when written but describes a moment rather than the workflow, and it goes stale the day #112 merges. No job, step or matrix entry is touched: 7 jobs, 17 runs, before and after. The reasoning that left the file is preserved in the two commits that added it and in the PR description. * Refresh the vendored utest.h to sheredom/utest.h@b6230bc The old copy is a pristine snapshot of utest.h@f4610ee. Since then upstream fixed the ILP32 constants and the NetBSD PRIu64 problem (#188), the test filter dropping tests it should run (#190) and added AIX support (#189). * Keep the PRI macros visible on NetBSD in C++98 <sys/param.h>, included here since #112 for __NetBSD_Version__, pulls in <sys/inttypes.h>. That header gates <machine/int_fmtio.h> on __STDC_FORMAT_MACROS for C++ before C++11 and sits behind an include guard, so anything defining the macro afterwards cannot get PRId64 and PRIu64 back. Consumers including subprocess.h first lost them silently; the test suite's C++98 translation unit is one. * Fall back to the compiler default where -std=c++2a is unknown too #105 added -std=c++2a for GCC 8 and clang 9, which do not know -std=c++20. GCC 7 and older know neither, so the fallback passed a flag those compilers reject and the build stopped before running anything. NetBSD 9.4 ships GCC 7.5.0 and hit exactly this. test20.cpp now drops the standard flag when neither spelling is available, which is what already happens for test11.c without c_std_11 and for MSVC, where no -std flag is passed at all. The suite then runs that translation unit at the compiler default rather than not at all. Measured in GCC 7.5.0: -std=c++20 and -std=c++2a are both rejected, and the file compiles clean at the default gnu++14 under the flags CMakeLists sets. GCC 13 still selects -std=c++20 and the suite stays at 444/444.

This was referenced Aug 1, 2026

Fix building where posix_spawn_file_actions_addchdir_np is unavailable #104

Merged

docs: LWJGL correction for BAF + upstream contribution tracking bernardladenthin/workspace#26

Merged

sheredom merged commit 907d50c into sheredom:main Aug 9, 2026
24 checks passed

bernardladenthin deleted the fix/test-cxx20-flag-fallback branch August 9, 2026 13:35

bernardladenthin mentioned this pull request Aug 10, 2026

Support AIX by forking where posix_spawn cannot change directory #112

Merged

Navigation Menu

Uh oh!

Fall back to -std=c++2a on compilers without -std=c++20 - #105

Fall back to -std=c++2a on compilers without -std=c++20#105
sheredom merged 1 commit into
sheredom:mainfrom
bernardladenthin:fix/test-cxx20-flag-fallback

bernardladenthin commented Aug 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

bernardladenthin commented Aug 1, 2026

Problem

Fix

Testing

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants