fix(alsa): timespec segfault with 64-bit time_t on 32-bit systems - #1285
Open
roderickvd wants to merge 2 commits into
Open
fix(alsa): timespec segfault with 64-bit time_t on 32-bit systems#1285roderickvd wants to merge 2 commits into
roderickvd wants to merge 2 commits into
Conversation
Member
Author
|
It fails to compile because you need to patch |
Member
Author
|
Despite the ongoing discussion over at diwic/alsa-rs#158, this patch seems correct, so I plan on merging it unless someone feels differently. |
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>
This was referenced Jul 26, 2026
diwic
pushed a commit
to diwic/alsa-sys
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
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.
This stacks with diwic/alsa-rs#158.
@d3d9