On 28/08/25 10:43, Paul Eggert wrote: > On 2025-08-28 01:42, Aleksa Sarai wrote: >>> I still fail to understand how a hypothetical "give me the supported flags" >>> openat2 flag would be useful enough to justify complicating the openat2 API >>> today. >> My only concern is that it would break recompiles if/when we change it >> back. > > OK, but from what I can see there's no identified possibility that openat2 will modify the objects its arguments point to, just as there's no identified possibility that plain openat will do so (in a hypothetical extension to remove unnecessary slashes from its filename argument, say). > > In that case it's pretty clear that glibc should mark the open_how argument as pointer-to-const, just as glibc already marks the filename argument. I am still not sure how a potentially CHECK_FIELDS feature would play with openat2 in the future, especially since glibc now prefers to first include the kernel headers before redefining a minimal API to the syscall usage (meaning that programs will have access to potentially new flags depending on the installed kernel header). If the kernel intends to modify the open_how in the future, setting open_how as const will only add extra confusion. Users might be exposed to this feature without explicitly including the kernel headers. Another option might to *not* include the kernel headers and keep syncing the kernel definitions on kernel releases (and maybe excluding flags that might modify the open_how). As Florian has said, this kind of mediation by glibc was historically time-consuming, complex, and subject to subtle bugs (and that's why we abandoned this over time).
