You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In musl, the struct ipc_perm has the fields __ipc_perm_key and __ipc_perm_seq. However, these are effectively internal-only names and are aliased to __key and __seq respectively. This is done in the sys/ipc.h header. This means, in C, you can effectively use either name.
For some reason this crate uses __ipc_perm_key, over __key. __key is used as the field name not only by the glibc struct in this crate, but also the newer architectures (loongarch64 and riscv32/riscv64). Strangely, the name __seq is used instead of __ipc_perm_seq in the same struct.
Because of this, I propose using __key instead. This will reduce the need for compile-time checks of API consumers, remove the seemingly musl-internal name, and increase consistency across architectures/libcs.`
(I'm working on a fix, just using this issue for tracking)
The text was updated successfully, but these errors were encountered:
Hello,
In
musl
, the structipc_perm
has the fields__ipc_perm_key
and__ipc_perm_seq
. However, these are effectively internal-only names and are aliased to__key
and__seq
respectively. This is done in thesys/ipc.h
header. This means, in C, you can effectively use either name.For some reason this crate uses
__ipc_perm_key
, over__key
.__key
is used as the field name not only by the glibc struct in this crate, but also the newer architectures (loongarch64 and riscv32/riscv64). Strangely, the name__seq
is used instead of__ipc_perm_seq
in the same struct.Because of this, I propose using
__key
instead. This will reduce the need for compile-time checks of API consumers, remove the seemingly musl-internal name, and increase consistency across architectures/libcs.`(I'm working on a fix, just using this issue for tracking)
The text was updated successfully, but these errors were encountered: