4 ms·

Because (a) I felt like it, (b) it would be more difficult to make raw syscalls in Rust, and (c) I use[1] flexible array members to minimize allocations, wherea

by 201984 2y ago

Because (a) I felt like it, (b) it would be more difficult to make raw syscalls in Rust, and (c) I use[1] flexible array members to minimize allocations, whereas Rust support for those quite bad[2]. It doesn't even look possible to allocate one with size known at runtime. [1]: https://codeberg.org/201984/dut/src/branch/master/main.c#L163 https://codeberg.org/201984/dut/src/branch/master/main.c#L16... [2]: https://doc.rust-lang.org/nomicon/exotic-sizes.html#dynamically-sized-types-dsts https://doc.rust-lang.org/nomicon/exotic-sizes.html#dynamica...

estebank 2y ago
> it would be more difficult to make raw syscalls in Rust Would you like to expand on this? Is it because of type conversions that you'd have to do? > I use[1] flexible array members to minimize allocations I was under the impression that FAM was a non-standard extension, but alas it is part of C99. From what I'm seeing you have intrusive list where each `entry` points to the previous and next element, where the path itself is a bag of bytes as part of the entry itself. I'm assuming that what you'd want from Rust is something akin to the following when it comes to the path? struct Entry<const NAME_LEN: usize> { .. mode: Mode, name: InlineName<NAME_LEN>, } struct InlineName<const NAME_LEN: usize> { value: [u8; NAME_LEN], }
- 201984 2y ago
  For syscalls, I would have needed to either pull in dependencies or write FFI bindings, and neither of those options are appealing when I could simply write the program in Linux's native language. For the FAM, your example looks like it requires a compile-time constant size. That's the same as hardcoding an array size in the struct, defeating the whole point. Short names will waste space, and long ones will get truncated.
  - estebank 2y ago
    > For the FAM, your example looks like it requires a compile-time constant size. That's the same as hardcoding an array size in the struct, defeating the whole point. Short names will waste space, and long ones will get truncated. You made me realize that the const generics stabilization work hasn't advanced enough to do what I was proposing (at least not in as straightforward way): https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=627f00ff95c8c9194158cd50de81d692 https://play.rust-lang.org/?version=nightly&mode=debug&editi... Those are const arguments, not const values, which means that you can operate on values as if they didn't have a size, while the compiler does keep track of the size throughout. I'd have to take a more detailed look to see if this level of dynamism is enough to work with runtime provided strings, which they might not be, unless you started encoding things like "take every CStr, create a StackString<1> for each char, and then add them together".

by 201984 2y ago

estebank 2y ago

> it would be more difficult to make raw syscalls in Rust Would you like to expand on this? Is it because of type conversions that you'd have to do? > I use[1] flexible array members to minimize allocations I was under the impression that FAM was a non-standard extension, but alas it is part of C99. From what I'm seeing you have intrusive list where each `entry` points to the previous and next element, where the path itself is a bag of bytes as part of the entry itself. I'm assuming that what you'd want from Rust is something akin to the following when it comes to the path? struct Entry<const NAME_LEN: usize> { .. mode: Mode, name: InlineName<NAME_LEN>, } struct InlineName<const NAME_LEN: usize> { value: [u8; NAME_LEN], }

201984 2y ago
For syscalls, I would have needed to either pull in dependencies or write FFI bindings, and neither of those options are appealing when I could simply write the program in Linux's native language. For the FAM, your example looks like it requires a compile-time constant size. That's the same as hardcoding an array size in the struct, defeating the whole point. Short names will waste space, and long ones will get truncated.
- estebank 2y ago
  > For the FAM, your example looks like it requires a compile-time constant size. That's the same as hardcoding an array size in the struct, defeating the whole point. Short names will waste space, and long ones will get truncated. You made me realize that the const generics stabilization work hasn't advanced enough to do what I was proposing (at least not in as straightforward way): https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=627f00ff95c8c9194158cd50de81d692 https://play.rust-lang.org/?version=nightly&mode=debug&editi... Those are const arguments, not const values, which means that you can operate on values as if they didn't have a size, while the compiler does keep track of the size throughout. I'd have to take a more detailed look to see if this level of dynamism is enough to work with runtime provided strings, which they might not be, unless you started encoding things like "take every CStr, create a StackString<1> for each char, and then add them together".