Support AIX in utest_ns() - #189
Merged
Merged
Conversation
AIX matches none of the platforms utest_ns() knows, so it falls through to #error Unsupported platform! and nothing builds there. It cannot share the Linux/BSD branch: that one calls timespec_get() when __STDC_VERSION__ >= 201112L, and AIX 7.2 does not have it. From the system's own /usr/include/time.h: 231:#define CLOCK_REALTIME ((clockid_t) 9) 238:extern int clock_gettime(clockid_t, struct timespec *); clock_gettime is there, timespec_get and TIME_UTC are not, so any translation unit compiled as C11 would fail. AIX gets its own branch instead. Verified on AIX 7.2 TL04 (7200-04-02-2027) on POWER8 with GCC 13.3.0: with this applied and -maix64, the test suite of a project that vendors utest.h builds and passes 441 of 441. Building in GCC's default 32-bit mode on AIX needs two further fixes, sent separately.
This was referenced Aug 10, 2026
bernardladenthin
added a commit
to bernardladenthin/utest.h
that referenced
this pull request
Aug 16, 2026
Reworked per review: keep PRId64/PRIu64 as the normal path and add a fallback only for the platforms that cannot print 64-bit integers, rather than changing how every target prints. The call sites pass integers again. UTEST_INT64_ARG/UTEST_UINT64_ARG expand to nothing on the normal path and to a double cast on the fallback, so there is still one call site per message. The fallback triggers where uint64_t is not unsigned long and the language has no ll length modifier — ILP32 under C90 or C++98. _MSC_VER is listed explicitly: Windows is LLP64, so unsigned long is 32 bits even on x64, and MSVC reports __cplusplus as 199711L without /Zc:__cplusplus, so neither of the other tests recognises it. Measured before adding it, MSVC took the fallback in all four of x86/x64 × C/C++. NetBSD needs no fallback at all: defining __STDC_FORMAT_MACROS before <inttypes.h> restores the PRI macros for C++98, which is what that header documents. Checked that it draws no -Wreserved-macro-identifier under clang. Which branch is live was measured, not assumed — a fallback that triggers everywhere would also build everywhere: x86_64, C gnu89/c99 and C++ gnu++98/c++17 native "lu"/"ld" i386, C gnu89 and C++ gnu++98 fallback ".0f" i386, C c99 and C++ c++11 native "llu"/"lld" MSVC 19.44 x86 and x64, C and C++ native "llu"/"lld" AIX 7.3 POWER10, 32- and 64-bit native "llu"/"lu" Suite green under gcc and under clang with -Weverything -Werror (2161), and under MSVC on both architectures (2173 run, 10 intentional Todo skips). Verified on real AIX 7.3 / POWER10, where GCC defaults to 32-bit and this PR matters most. With sheredom#189 applied for platform support, subprocess.h's suite builds and passes 443 tests at 32- and at 64-bit; without this change the 32-bit build still fails on the oversized constants. Both paths coexist there in one binary, since that suite compiles some translation units at -std=gnu89 and -std=gnu++98 and the rest at newer standards. NetBSD's C++98 path is the one thing not reproducible locally — sheredom#113's netbsd 10.1 job covers it.
sheredom
pushed a commit
that referenced
this pull request
Aug 17, 2026
Reworked per review: keep PRId64/PRIu64 as the normal path and add a fallback only for the platforms that cannot print 64-bit integers, rather than changing how every target prints. The call sites pass integers again. UTEST_INT64_ARG/UTEST_UINT64_ARG expand to nothing on the normal path and to a double cast on the fallback, so there is still one call site per message. The fallback triggers where uint64_t is not unsigned long and the language has no ll length modifier — ILP32 under C90 or C++98. _MSC_VER is listed explicitly: Windows is LLP64, so unsigned long is 32 bits even on x64, and MSVC reports __cplusplus as 199711L without /Zc:__cplusplus, so neither of the other tests recognises it. Measured before adding it, MSVC took the fallback in all four of x86/x64 × C/C++. NetBSD needs no fallback at all: defining __STDC_FORMAT_MACROS before <inttypes.h> restores the PRI macros for C++98, which is what that header documents. Checked that it draws no -Wreserved-macro-identifier under clang. Which branch is live was measured, not assumed — a fallback that triggers everywhere would also build everywhere: x86_64, C gnu89/c99 and C++ gnu++98/c++17 native "lu"/"ld" i386, C gnu89 and C++ gnu++98 fallback ".0f" i386, C c99 and C++ c++11 native "llu"/"lld" MSVC 19.44 x86 and x64, C and C++ native "llu"/"lld" AIX 7.3 POWER10, 32- and 64-bit native "llu"/"lu" Suite green under gcc and under clang with -Weverything -Werror (2161), and under MSVC on both architectures (2173 run, 10 intentional Todo skips). Verified on real AIX 7.3 / POWER10, where GCC defaults to 32-bit and this PR matters most. With #189 applied for platform support, subprocess.h's suite builds and passes 443 tests at 32- and at 64-bit; without this change the 32-bit build still fails on the oversized constants. Both paths coexist there in one binary, since that suite compiles some translation units at -std=gnu89 and -std=gnu++98 and the rest at newer standards. NetBSD's C++98 path is the one thing not reproducible locally — #113's netbsd 10.1 job covers it.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
AIX matches none of the platforms
utest_ns()knows, so it falls through to#error Unsupported platform!and nothing builds there.grep -c _AIX utest.hreturns 0.
It cannot simply join the Linux/BSD branch. That one calls
timespec_get(&ts, TIME_UTC)when__STDC_VERSION__ >= 201112L, and AIX 7.2does not have it. From the system's own header:
clock_gettimeis there;timespec_getandTIME_UTCare not. Adding_AIXto the existing list would therefore compile in C89 and C99 and fail in C11 —
which is exactly the kind of thing that only shows up later. So AIX gets its
own branch, using
clock_gettimeunconditionally.Verification
Measured on AIX 7.2 TL04 (7200-04-02-2027) on POWER8, GCC 13.3.0. With this
applied and
-maix64, the test suite of a project that vendors utest.h buildsand passes 441 of 441. Without it the build stops at the
#error.No other platform is touched — the change is two
#elifblocks, +7 lines.Building on AIX in GCC's default 32-bit mode additionally needs the fixes in
#188, which are unrelated to AIX and also affect i386 Linux. Either PR
stands on its own; both are needed for 32-bit AIX.