4 ms·

you can assign a new object into buf in C just fine, with "buf = (struct YourType){.prop1 = a, .prop2 = b}"; it even zero-initializes unset fields! So C and R

by dzaima 5y ago

you can assign a new object into *buf in C just fine, with "*buf = (struct YourType){.prop1 = a, .prop2 = b}"; it even zero-initializes unset fields! So C and Rust give you precisely the same abilities here. edit: the "struct pipe_buffer" in question[1] has one field that even the updated code doesn't write - "private". Not sure what it's about, but it's there. Not writing unrelated fields like that is probably not much of an issue now, but it certainly can add up on low-power systems. You might also have situations where you'd want to write parts of an object in different parts of the code, for which you'd have to resort to writing fields manually. [1]: https://github.com/torvalds/linux/blob/719fce7539cd3e186598e2aed36325fe892150cf/include/linux/pipe_fs_i.h#L17-L32 https://github.com/torvalds/linux/blob/719fce7539cd3e186598e...

deredede 5y ago
Oh I was not aware of this syntax in C, thanks for bringing it up! I still think the pattern is more common and known in Rust but I might be wrong :) Re: your other points, "reusing a pre-allocated struct from a buffer" is basically object initialization, which is different from other times you want to write fields. In general an object initialization construct should be used in those cases, this whole thread being an argument why. Out-of-band fields such as the "private" field are a pain I agree, but they can be separated from an inner struct (in which case the inner struct is the only field that gets assigned for initialization). Taking a step back, the true solution is probably to have a proper constructor... And that can be done in any language, so I'll stand corrected.
- dzaima 5y ago
  The question of safety is often much more about coding standards than actual language features. For a kernel, you'd be violating Rust's safety features left right and center (or have a slow kernel that just dies on OOM; choose one) and would have to come up with your own standards for preventing coding errors in those, which is what you already have with C. To be clear, some base level of trivially safe code is certainly a nice-to-have. I just don't think the amount that helps for a kernel is that much, and the added boilerplate on more unsafe things might even obscure issues.
db48x 5y ago
I think you need to have C99 for that, and the kernel is still using C89. If C needs to die, then C89 needs to die first :)
- dzaima 5y ago
  as far as I understand, the kernel uses C89 + GNU extensions, cause there definitely are usages in the kernel of it. (my searching showed it being only used for defining globals, which is a weird standard, but I don't see anything preventing using it elsewhere if they wanted to) And there are recent plans to move the kernel to a newer C version anyway.

you can assign a new object into *buf in C just fine, with "*buf = (struct YourType){.prop1 = a, .prop2 = b}"; it even zero-initializes unset fields! So C and R

by dzaima 5y ago

deredede 5y ago

Oh I was not aware of this syntax in C, thanks for bringing it up! I still think the pattern is more common and known in Rust but I might be wrong :) Re: your other points, "reusing a pre-allocated struct from a buffer" is basically object initialization, which is different from other times you want to write fields. In general an object initialization construct should be used in those cases, this whole thread being an argument why. Out-of-band fields such as the "private" field are a pain I agree, but they can be separated from an inner struct (in which case the inner struct is the only field that gets assigned for initialization). Taking a step back, the true solution is probably to have a proper constructor... And that can be done in any language, so I'll stand corrected.

dzaima 5y ago
The question of safety is often much more about coding standards than actual language features. For a kernel, you'd be violating Rust's safety features left right and center (or have a slow kernel that just dies on OOM; choose one) and would have to come up with your own standards for preventing coding errors in those, which is what you already have with C. To be clear, some base level of trivially safe code is certainly a nice-to-have. I just don't think the amount that helps for a kernel is that much, and the added boilerplate on more unsafe things might even obscure issues.

db48x 5y ago

I think you need to have C99 for that, and the kernel is still using C89. If C needs to die, then C89 needs to die first :)

dzaima 5y ago
as far as I understand, the kernel uses C89 + GNU extensions, cause there definitely are usages in the kernel of it. (my searching showed it being only used for defining globals, which is a weird standard, but I don't see anything preventing using it elsewhere if they wanted to) And there are recent plans to move the kernel to a newer C version anyway.