Sebastien Marie <sema...@online.fr> wrote: > On Fri, Sep 10, 2021 at 08:12:58AM -0600, Theo de Raadt wrote: > > > for Rust programs. It should even be free as Rust libc crate doesn't > > > have `struct kinfo_proc` definition. I can't comment on Go side. > > > > The structure has nothing to do with libc! > > > > So why would it occur there? > > Because Rust libc is where Rust developers puts all the OS stuff. > > The `struct kinfo_vmentry' or `struct kinfo_proc` on FreeBSD is > defined in Rust libc crate for example. > > https://github.com/rust-lang/libc/blob/master/src/unix/bsd/freebsdlike/freebsd/mod.rs#L173
They have lost the plot. Decisions will be made as follows -- does rust get to define change policy, or do systems get to define change policy, when they encounter a mistake they made. Systems contain mistakes. Not all mistakes can be fixed without ABI or API change. What is being proposed is a fix that requires ABI change. Rust policy is irrelevant, they are out of scope, and the 'policy' / 'implimentation' you describe is going to bear them consequences eventually on *ALL SYSTEMS INTERFACES IN ALL SYSTEMS*, because their requirement is completely unreasonable. Not even Linux is as stable as they want, over a decade. What I find amazing here is that rust is not a source-code focused language. What you have described is making binary data authoritative rather than source.
