fix: probe time_t width at build time on 32-bit glibc targets - #19
Merged
Conversation
diwic
reviewed
Jun 24, 2026
Owner
|
@roderickvd Cool, so one remaining question then - we need to do the same with |
Contributor
Author
|
You are right, same problem. Done in 7675e45. |
Owner
|
@roderickvd Okay, let's merge it and see if it breaks something for someone else. If it does, I might revert. |
Contributor
Author
|
👍 I like that approach. |
b0bbywan
added a commit
to b0bbywan/alsa-sys
that referenced
this pull request
Jul 26, 2026
__TIMESIZE reports the port's default time_t width, so it still reads 32 on targets that gained a 64-bit time_t through Debian's time64 transition (_TIME_BITS=64 in the toolchain, e.g. armhf on trixie). On those targets the probe from diwic#19 does not emit alsa_sys_time64, libc::timespec stays 8 bytes, and libasound writes 16-byte timespecs past it (diwic/alsa-rs#158, RustAudio/cpal#1285). Measure the size directly instead: try to compile a _Static_assert that sizeof(struct timespec) == 16. The snippet is compiled but never run, so cross compiling against the target's sysroot keeps working. A control compile first checks that <time.h> yields a usable timespec, so a broken toolchain produces a warning and the safe 32-bit fallback instead of being misread as a pre-transition target. Verified on Raspberry Pi OS armhf: with this change the cfg is emitted on trixie (16-byte timespec) and still not on bookworm (8-byte timespec). 64-bit glibc and musl targets return early as before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
diwic
pushed a commit
that referenced
this pull request
Jul 29, 2026
* fix: measure sizeof(struct timespec) instead of reading __TIMESIZE __TIMESIZE reports the port's default time_t width, so it still reads 32 on targets that gained a 64-bit time_t through Debian's time64 transition (_TIME_BITS=64 in the toolchain, e.g. armhf on trixie). On those targets the probe from #19 does not emit alsa_sys_time64, libc::timespec stays 8 bytes, and libasound writes 16-byte timespecs past it (diwic/alsa-rs#158, RustAudio/cpal#1285). Measure the size directly instead: try to compile a _Static_assert that sizeof(struct timespec) == 16. The snippet is compiled but never run, so cross compiling against the target's sysroot keeps working. A control compile first checks that <time.h> yields a usable timespec, so a broken toolchain produces a warning and the safe 32-bit fallback instead of being misread as a pre-transition target. Verified on Raspberry Pi OS armhf: with this change the cfg is emitted on trixie (16-byte timespec) and still not on bookworm (8-byte timespec). 64-bit glibc and musl targets return early as before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: probe snd_htimestamp_t via the ALSA headers and fail on probe errors Review feedback from #20: - Measure sizeof(snd_htimestamp_t) from <alsa/asoundlib.h> instead of struct timespec from <time.h>: it is the exact type libasound writes through. The probe now runs after pkg-config so it can reuse the reported include paths. The alsa/ prefix is required since alsa-lib 1.2.5, when alsa.pc stopped adding -I${includedir}/alsa. - If the control snippet does not compile, fail the build with an explicit error instead of assuming a 32-bit time_t: guessing 8 can segfault and guessing 16 yields garbage timestamps, so there is no safe fallback to pick silently. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Alternative to #18 that probes the real
time_twidth at build time instead of inferring it from the resulting bytes at runtime.What this gets that #18 can't:
snd_timer_status_get_timestampand_snd_timer_treadpasstimespecby value, where the ABI depends on the real size. Oversizing can regress currently-working 32-bittime32systems. This is what Copilot triggered on Experimental autodetection of 64 bit timespec on 32 bit platforms #18.is64()edge cases liketv_nsecbeing exactly 0.timespeckeeps the sametv_sec/tv_nsecfields aslibc::timespec, so it's all the same downstream.What it costs isa new build-time dependency on
ccfor a working preprocessor. I think that shouldn't be a problem as anyone trying to buildalsa-sysneeds a working build environment anyway.