Messages in this thread | | | Date | Sat, 17 Apr 2021 00:04:16 +0200 | From | Willy Tarreau <> | Subject | Re: [PATCH 04/13] Kbuild: Rust support |
| |
On Fri, Apr 16, 2021 at 11:39:00PM +0200, Miguel Ojeda wrote: > On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau <w@1wt.eu> wrote: > > > > No, two: > > - ok in %rax (seems like it's "!ok" technically speaking since it > > returns 1 on !ok and 0 on ok) > > - foo_or_err in %rdx > > Yes, but that is the implementation -- conceptually you only have one > or the other, and Rust won't allow you to use the wrong one.
OK so for unions you always pass two values along the whole chain, a selector and the value itself.
But my point remains that the point of extreme care is at the interface with the rest of the kernel because there is a change of semantics there.
> > However then I'm bothered because Miguel's example showed that regardless > > of OK, EINVAL was always returned in foo_or_err, so maybe it's just > > because his example was not well chosen but it wasn't very visible from > > the source: > > That is the optimizer being fancy since the error can be put > unconditionally in `rdx`.
Yes that's what I understood as well. I just didn't know that it had to be seen as a union.
On Fri, Apr 16, 2021 at 11:19:18PM +0200, Miguel Ojeda wrote: > On Fri, Apr 16, 2021 at 10:22 PM Willy Tarreau <w@1wt.eu> wrote: > > > > So it simply does the equivalent of: > > > > struct result { > > int status; > > int error; > > }; > > Not exactly, it is more like a tagged union, as Connor mentioned. > > However, and this is the critical bit: it is a compile-time error to > access the inactive variants (in safe code). In C, it is on you to > keep track which one is the current one.
Sure but as I said most often (due to API or ABI inheritance), both are already exclusive and stored as ranges. Returning 1..4095 for errno or a pointer including NULL for a success doesn't shock me at all.
Along thes lines I hardly see how you'd tag pointers by manipulating their lower unused bits. That's something important both for memory usage and performance (supports atomic opts).
> > kill_foo(); // only for rust, C doesn't need it > > Please note that `kill_foo()` is not needed in Rust -- it was an > example of possible cleanup (since Al mentioned resources/cleanup) > using RAII.
Yep but I kept it just to have comparable output code since in C you'd simply use "goto leave" and not have this function call to do the cleanup.
Willy
| |