On 2026-07-19 10:21, Luca Boccassi wrote:
On Sat, 18 Jul 2026 at 07:46, Paul Eggert <[email protected]> wrote:
For this one, two general issues:
* This implementation doesn't appear to be thread-safe.
Switched to using the 'once' module
Many programs that Gnulib's selinux-h module are single-threaded. 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.
It doesn't make a lot of sense for each function to do its own dlsym,
as the common dlopen object is needed anyway, so might as well set up
all symbols immediately.
Although that's true for some applications, it's not true for all.
Whether it makes sense to call dlsym eagerly depends at least in part on
the application's preferred style for linking. As I understand it wget2,
octave, and libvirt defer calling dlsym until a symbol is needed, at
least for some symbols.
An explicit initialization seems overkill,
libselinux has implicit global state anyway, it doesn't operate only
on explicit caller-owned objects, so it makes things more complex and
annoying to use, for little benefit.
Hmm, my intuition is just the opposite, namely, since libselinux has
global state the application needs to be somewhat careful in messing
with that state, and so needs a way to configure libselinux safely in a
single thread before letting
What if the app has libselinux linked in for other reasons, before
'main' even starts? Would that collide with the draft patch? That is,
does the draft patch insist that Gnulib be the only way to use
libselinux functionality?
Any word on this? Would the patch cause libselinux to be linked twice?
I'm a bit fuzzy on the details.
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.
Why include <sys/stat.h> and depend on sys_stat-h?
For the definition of S_ISREG and friends
Thanks for explaining; I missed that.
