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.
For many single-threaded programs the trend is more to keep things simple, and avoid
'once'. For example, yesterday I installed a patch to GNU 'grep' to do just that in
some obscure configuration scenarios; see <https://bugs.gnu.org/81515>.
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.
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.
