Hello,
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)
Hello,
In
musl, the structipc_permhas the fields__ipc_perm_keyand__ipc_perm_seq. However, these are effectively internal-only names and are aliased to__keyand__seqrespectively. This is done in thesys/ipc.hheader. This means, in C, you can effectively use either name.For some reason this crate uses
__ipc_perm_key, over__key.__keyis 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__seqis used instead of__ipc_perm_seqin the same struct.Because of this, I propose using
__keyinstead. 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)