go-pathrs: don't derive ProcBase from the C enum - #408
Conversation
cbindgen v0.29.3 emits the C23 fixed-type enum syntax for sized enums[1], so in C23 mode pathrs_proc_base_t names the enum rather than uint64_t. CGo maps a C enum to a *signed* Go type, so none of the open-coded ProcBase constants fit in it any more and the package stops compiling: > internal/libpathrs/libpathrs_linux.go:228:22: cannot use > 0xFFFF_FFFE_7072_6F63 (untyped int constant 18446744067006164835) as > ProcBase value in constant declaration (overflows) Our own tree does not show this, because CI is pinned to cbindgen v0.29.2[2], so the checked-in header and the release tarball still typedef uint64_t. Fedora (and presumably other distros) do hit it, because they build the crate with `cargo-c`, which generates the header with its own cbindgen. Fedora rawhide has cbindgen v0.29.4 and gcc 16, which defaults to C23, so libpathrs-devel-0.2.5-2.fc45 ships the C23 spelling and every Go consumer of it fails to build. The workaround there is to force the older language version with `CGO_CFLAGS=-std=gnu17`. Declare the type as plain uint64 instead, which is what the docstring already promises. That also holds up under the direction discussed in [1], where the #if guards would be dropped in favour of an opt-out and the enum spelling would become unconditional. Nothing else has to change: the values were already converted with C.pathrs_proc_base_t() at each call site, and init() already reads the C constants through int64 temporaries because CGo signs those too. [1]: mozilla/cbindgen#1156 [2]: cyphar#383 Signed-off-by: Martin Pitt <martin@amutable.com>
|
Related: #382 (comment) |
|
Whoa whoa, you can't use The behaviour here is quite complicated, as I outlined in #382. (There is also a separate type issue when building with clang which this will also cause issues with AFAICS.) |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
The package does
That's only true for your upstream build/CI. That works because #383 pins the older cbindgen. But If you want, I can talk you through standing up some actual Fedora CI in upstream PRs, with packit. (Or send a PR 😉 ) |
|
Hmm, I must've misremembered. I expected the |
2 participants
cbindgen v0.29.3 emits the C23 fixed-type enum syntax for sized enums1, so in C23 mode pathrs_proc_base_t names the enum rather than uint64_t. CGo maps a C enum to a signed Go type, so none of the open-coded ProcBase constants fit in it any more and the package stops compiling:
Our own tree does not show this, because CI is pinned to cbindgen v0.29.22, so the checked-in header and the release tarball still typedef uint64_t. Fedora (and presumably other distros) do hit it, because they build the crate with
cargo-c, which generates the header with its own cbindgen. Fedora rawhide has cbindgen v0.29.4 and gcc 16, which defaults to C23, so libpathrs-devel-0.2.5-2.fc45 ships the C23 spelling and every Go consumer of it fails to build. The workaround there is to force the older language version withCGO_CFLAGS=-std=gnu17.Declare the type as plain uint64 instead, which is what the docstring already promises. That also holds up under the direction discussed in 1, where the #if guards would be dropped in favour of an opt-out and the enum spelling would become unconditional.
Nothing else has to change: the values were already converted with C.pathrs_proc_base_t() at each call site, and init() already reads the C constants through int64 temporaries because CGo signs those too.