On Tue, Mar 3, 2026 at 6:04 PM Michel Dänzer <[email protected]> wrote: > > On 3/3/26 17:54, Julian Orth wrote: > > On Tue, Mar 3, 2026 at 5:40 PM Maarten Lankhorst > > <[email protected]> wrote: > >> > >> There is precedence in the ioctl, the pad member is checked against zero > >> for the same reason. > > > > I don't believe that this is comparable. Developers of code developed > > against an older kernel could look at the kernel and see that the pad > > field was checked against zero. They could not see the same for fields > > that didn't exist at the time. > > "Initialize only known fields" isn't a valid approach here. The full struct > must be initialized to 0, including any fields added in the future.
It worked from the introduction of the ioctl until the new field was added. How could anyone know about this requirement if it is not documented? Some people might not even know that ioctl numbers encode the size of the argument and therefore assume that the argument structure is fixed. I think this is quite different from syscalls such as clone3 which make the size argument explicit and where it can be expected that the developer knows that the struct might grow when the application is recompiled. The new flag was added so that userspace can detect older kernels that don't support the point field, such kernels return EINVAL when they see the new flag. Then why should the kernel not also use the absence of the flag to detect older userspace that might be unaware of the point field? > > > -- > Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer > https://redhat.com \ Libre software enthusiast
