4 ms·

While correct, everything is a number at the ABI boundary, so it’s still possible - if not harder. Depending on the layout and arch, -2 could well represent Te

by orf 2y ago

While correct, everything is a number at the ABI boundary, so it’s still possible - if not harder. Depending on the layout and arch, -2 could well represent Terminated

nneonneo 2y ago
I think this misunderstands how Rust enums work. The discriminator is separate from the payload, unless niches are involved (they probably wouldn’t be here - note that -2 is a valid pid_t). You cannot go and pass a Rust enum to any FFI function directly (without extra annotations, at least); you’d have to specifically extract the pid_t from the enum before passing it to an FFI function like kill(). And you can only obtain a pid_t from the Pid variant; if the enum holds a different variant, the compiler will stop you from trying to pull out a pid_t.
- orf 2y ago
  I understand how Rust enums work, but you’re misunderstanding how ABIs work (or my original point, or both). Rust enums are a Rust concept. Two identical enums will have different memory layouts on different machines, Rust versions, etc. Even if this was solved, you’re still passing the enum across a boundary. Both sides need to agree on the layout of the enum in memory. To illustrate the problem, imagine we had two variants: `Pid(NonZeroUsize), LaunchTheNukes` This can be laid out in memory with a single `usize`: the 0 value becomes the discriminate for `LaunchTheNukes`. Thus, if you pass `0` (I.e null) across the boundary the other side will interpret it as `LaunchTheNukes`. In short, if you naively change the layout of an enum and don’t recompile everything that uses the enum (i.e the kernel) then your -2 value could change from being interpreted as `Pid(-2)` in the application to `LaunchTheNukes` in the kernel. It gets more complex with larger enums and more discriminators, but the general point is that the concepts of enums, type safety and such doesn’t really exist across boundaries like syscalls, because it doesn’t exist in hardware / at the machine level.

by orf 2y ago

While correct, everything is a number at the ABI boundary, so it’s still possible - if not harder. Depending on the layout and arch, -2 could well represent Terminated

nneonneo 2y ago

I think this misunderstands how Rust enums work. The discriminator is separate from the payload, unless niches are involved (they probably wouldn’t be here - note that -2 is a valid pid_t). You cannot go and pass a Rust enum to any FFI function directly (without extra annotations, at least); you’d have to specifically extract the pid_t from the enum before passing it to an FFI function like kill(). And you can only obtain a pid_t from the Pid variant; if the enum holds a different variant, the compiler will stop you from trying to pull out a pid_t.

orf 2y ago
I understand how Rust enums work, but you’re misunderstanding how ABIs work (or my original point, or both). Rust enums are a Rust concept. Two identical enums will have different memory layouts on different machines, Rust versions, etc. Even if this was solved, you’re still passing the enum across a boundary. Both sides need to agree on the layout of the enum in memory. To illustrate the problem, imagine we had two variants: `Pid(NonZeroUsize), LaunchTheNukes` This can be laid out in memory with a single `usize`: the 0 value becomes the discriminate for `LaunchTheNukes`. Thus, if you pass `0` (I.e null) across the boundary the other side will interpret it as `LaunchTheNukes`. In short, if you naively change the layout of an enum and don’t recompile everything that uses the enum (i.e the kernel) then your -2 value could change from being interpreted as `Pid(-2)` in the application to `LaunchTheNukes` in the kernel. It gets more complex with larger enums and more discriminators, but the general point is that the concepts of enums, type safety and such doesn’t really exist across boundaries like syscalls, because it doesn’t exist in hardware / at the machine level.