6 ms·

Why C and not Rust or even Zig?

by miew 2y ago

Galanwe 2y ago
Why Rust or Zig and not C?
- nottorp 2y ago
  Better for the author's resume, if they want to make it hype driven. Also some nebulous "being more secure". Never mind that this tool does not have elevated privileges. You gotta watch out for those remote root exploits even for a local only app, man.
  - _flux 2y ago
    I mean you could extract an archive you've downloaded to your filesystem and said archive could have funky file names and then you use this tool.. But I suppose it's not a very likely bug to have in this kind of tool.
    - nottorp 2y ago
      Or “they” could enter your house at 2 am, drug you and hit you with a $5 wrench until they get access to your files :)
      - gsck 2y ago
        Never understood this line of thought. Not everything needs to be super secure. Not everything is going to be an attack vector. No one is going to deploy this onto a production server where this program specifically is going to be the attack vector. Memory safety is cool and all, but a program that effectively sums a bunch of numbers together isn't going to cause issues. Worst case the program segfaults
craftoman 2y ago
Because C is like a cult Toyota Supra with twin turbo and Rust or Zig is like another cool boring Corvette roadster.
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".
estebank 2y ago
This is not an appropriate question to ask, that I see sometimes in these threads. "Because the author wanted" is good enough a reason for them to write a program in C. It being a new project written in C can also be good enough reason for you not to use it: dust already exists and is written in Rust, which you can use instead.

Why C and not Rust or even Zig?

by miew 2y ago

Why C and not Rust or even Zig?

Galanwe 2y ago

Why Rust or Zig and not C?

nottorp 2y ago
Better for the author's resume, if they want to make it hype driven. Also some nebulous "being more secure". Never mind that this tool does not have elevated privileges. You gotta watch out for those remote root exploits even for a local only app, man.
- _flux 2y ago
  I mean you could extract an archive you've downloaded to your filesystem and said archive could have funky file names and then you use this tool.. But I suppose it's not a very likely bug to have in this kind of tool.
  - nottorp 2y ago
    Or “they” could enter your house at 2 am, drug you and hit you with a $5 wrench until they get access to your files :)
    - gsck 2y ago
      Never understood this line of thought. Not everything needs to be super secure. Not everything is going to be an attack vector. No one is going to deploy this onto a production server where this program specifically is going to be the attack vector. Memory safety is cool and all, but a program that effectively sums a bunch of numbers together isn't going to cause issues. Worst case the program segfaults

craftoman 2y ago

Because C is like a cult Toyota Supra with twin turbo and Rust or Zig is like another cool boring Corvette roadster.

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".

estebank 2y ago

This is not an appropriate question to ask, that I see sometimes in these threads. "Because the author wanted" is good enough a reason for them to write a program in C. It being a new project written in C can also be good enough reason for you not to use it: dust already exists and is written in Rust, which you can use instead.