I have spent a bit of time checking the library ecosystem for problems, when switching to a libc build that uses --cfg gnu_time_bits64.
One thing I caught is, that in nix e.g. the suseconds_t type is used as part of the public API (for example
|
pub const fn new(seconds: time_t, microseconds: suseconds_t) -> Self { |
).
When the gnu_time_bits64 flag is enabled on build, some types change. For example time_t is redefined as a 64 bit value.
In the timeval case here however, the struct is redefined, with a type we can not get hold of in a generic way as a consumer of libc.
The tv_usec is replaced directly in timeval, no redefinition of suseconds_t. Presumably, this is done, because in glibc suseconds_t was also not redefined conditionally on _TIME_BITS=64 builds.
This creates a problem in the nix crate. We can not get access to the type for purpose in function signatures etc... from libc. We also can not
depend on the --cfg gnu_time_bits64 cfg from the libc crate. As far as I am aware, cfg flags of your dependencies can not be accessed with rustc / cargo.
The question is, how can we solve this problem in a sane way? Locally, I have already patched stdlib, libc, etc... anyways, I just decided to
put in some types like timeval_field_tv_usec_t etc... , then just use them in nix and other crates.
What I am thinking now is: does nix really need to expose suseconds_t at all in its API surface? Can it not just default to a 64 bit integer instead in the public API? I know its probably a bit of a waste, but it seems like a solution, that would work on 64 bit systems, 32 bit systems that always defaulted to 64 bit time types, 32 bit systems that use a new 64 bit time ABI, and also legacy 32 bit systems.
I have spent a bit of time checking the library ecosystem for problems, when switching to a libc build that uses --cfg gnu_time_bits64.
One thing I caught is, that in nix e.g. the suseconds_t type is used as part of the public API (for example
nix/src/sys/time.rs
Line 621 in 69c0505
When the gnu_time_bits64 flag is enabled on build, some types change. For example time_t is redefined as a 64 bit value.
In the timeval case here however, the struct is redefined, with a type we can not get hold of in a generic way as a consumer of libc.
The tv_usec is replaced directly in timeval, no redefinition of suseconds_t. Presumably, this is done, because in glibc suseconds_t was also not redefined conditionally on _TIME_BITS=64 builds.
This creates a problem in the nix crate. We can not get access to the type for purpose in function signatures etc... from libc. We also can not
depend on the --cfg gnu_time_bits64 cfg from the libc crate. As far as I am aware, cfg flags of your dependencies can not be accessed with rustc / cargo.
The question is, how can we solve this problem in a sane way? Locally, I have already patched stdlib, libc, etc... anyways, I just decided to
put in some types like timeval_field_tv_usec_t etc... , then just use them in nix and other crates.
What I am thinking now is: does nix really need to expose suseconds_t at all in its API surface? Can it not just default to a 64 bit integer instead in the public API? I know its probably a bit of a waste, but it seems like a solution, that would work on 64 bit systems, 32 bit systems that always defaulted to 64 bit time types, 32 bit systems that use a new 64 bit time ABI, and also legacy 32 bit systems.