Closed tatref closed 1 year ago
I have no objection to this change, but I want to do some digging to quell the niggling feeling in the back of my mind that I had (once upon a time) a good reason to pick i32
Maybe because libc pid_t
is i32?
Also maybe because the proc.5
page says that when parsing /proc/pid/stat
, the PID field should be parsed with %d
(which is a signed int).
You are correct! Seems like this is already known: https://internals.rust-lang.org/t/std-child-pid-type-compatibility/10473/1
I guess this is not worth pursuing
Ok, let's keep the current i32
for now. Thanks for testing this, though.
See issue #245
I tried to convert all the i32 fields to u32 for Process and Task. I only had to mess a bit with the display code for the example lslocks.
Cargo check and test are OK, and I tested all the examples, everything works as expected
Feel free to discard this PR if you prefer to keep the current i32.