undefined | Better HN

0 pointsdzaima4y ago0 comments

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/719fce7539cd3e186598e...

0 comments

4 comments · 2 top-level

deredede4y ago· 1 in thread

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.

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

db48x4y ago· 1 in thread

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 :)

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

j / k navigate · click thread line to collapse

0 comments

4 comments · 2 top-level

deredede4y ago· 1 in thread

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 :)

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.

dzaimaOP4y ago

db48x4y ago· 1 in thread

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 :)

dzaimaOP4y ago

And there are recent plans to move the kernel to a newer C version anyway.

j / k navigate · click thread line to collapse