On Thu, 30 Jul 2026 at 21:15, Paul Eggert <[email protected]> wrote: > > On 2026-07-30 12:42, Luca Boccassi wrote: > > >> There > >> should be some way for them to use selinux-h without also dragging in > >> the 'once' module. Bruno may be able to help here, as he knows more > >> about multithreading. > > > > Isn't that a huge footgun to leave lying around otherwise? > > It's more the other way. Once you drag in 'once' you pull in other > multi-threading code and ideas. It's more of a pain to maintain, because it > isn't obvious to developers that everything is actually single-threaded. And > there are more ways to go wrong, with a bigger attack surface for the > executable.
I don't see any evidence of that. There's nothing a developer needs to do, as it's completely self-contained and transparent - it's not like it's creating or managing threads, it's just an internal spinlock. In a single-threaded caller it's a no-op. > > Having to remember to synchronize two layers of global state would be > > a gigantic pain for consumers > > My intuition is more the other way: because libselinux already has global > state that is a gigantic pain for its users, trying to hide that from users > does them a disservice. This is not an issue of saving implementation > details: it's an issue of making things clear to users. Nothing is hidden, the library works exactly as it always did. Its internals are its own, and have to be dealt with regardless. It is simply pointless to add another dimension to the problem that _also_ has to be handled, separately. > >>>> Why depend on stddef-h? > >>> > >>> For the definition of NULL > >> > >> I would think that every stddef.h in a Gnulib porting target already > >> defines NULL well enough for selinux-h. A dependency on stddef-h is > >> needed only if selinux-h would otherwise run afoul of the problems noted > >> in doc/posix-headers/stddef.texi, problems that Gnulib fixes. > >> > >> Admittedly this is a minor point. > > > > The coreutils build yelled at me without it, so it seems not > > What were the symptoms? This suggests a more-serious problem, and if so I'd > rather not paper over it. Actually I've just checked again, and it doesn't fail to build in the current revision, I imagine earlier changes brought the definition back in, so I'll drop it in the next revision
