On Thu, Mar 9, 2023 at 9:24 PM Faith Ekstrand <faith.ekstrand@xxxxxxxxxxxxx> wrote: > > On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote: > > On 08/03/2023 02.34, Björn Roy Baron wrote: > > > > + // SAFETY: This is just the ioctl > > > > argument, which hopefully has the right type > > > > + // (we've done our best checking the > > > > size). > > > > > > In the rust tree there is the ReadableFromBytes [1] trait which > > > indicates that it is safe to read arbitrary bytes into the type. > > > Maybe you could add it as bound on the argument type when it lands > > > in rust-next? This way you can't end up with for example a struct > > > containing a bool with the byte value 2, which is UB. > > > > There's actually a much bigger story here, because that trait isn't > > really very useful without a way to auto-derive it. I need the same > > kind > > of guarantee for all the GPU firmware structs... > > > > There's one using only declarative macros [1] and one using proc > > macros > > [2]. And then, since ioctl arguments are declared in C UAPI header > > files, we need a way to be able to derive those traits for them... > > which > > I guess means bindgen changes? > > It'd be cool to be able to auto-verify that uAPI structs are all > tightly packed and use the right subset of types. Maybe not possible > this iteration but it'd be cool to see in future. I'd like to see it > for C as well, ideally. > > ~Faith > I'm sure that with a macro you could verify that a struct definition doesn't contain any gaps, just not sure on how one would enforce that. Could add a trait which can only be implemented through a proc_macro? Maybe we can have a proc_macro ensuring no gaps? Would be cool tech to have indeed.
