[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <emda7fe876-df00-48b8-88e5-68bddf86b789@a532f72a.com>
Date: Thu, 11 Apr 2024 11:44:16 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Increase NGROUPS_MAX from 32 to 1024
>I had a look at Debian Codesearch for NGROUPS_MAX, to see what
>applications are actually doing with the macro. And I found no instance
>of anyone using it as an array size.
I do. e.g.
https://git.skarnet.org/cgi-bin/cgit.cgi/s6/tree/src/daemontools-extras/s6-applyuidgid.c#n22
It's in small short-lived utilities that don't allocate anything, so
I'm
not too worried about overflowing the stack, but the change would not be
friendly to resource-constrained environments.
My code runs on not-so-conformant systems such as Solaris or MacOS,
where
I'm not sure that sysconf() and _SC_NGROUPS_MAX are even defined and
correct.
I can test, but that's more work, and convoluted heuristics to make
things
support every case are a strong decrease in readability and reliability,
an additional portability nightmare I don't want to deal with. Whereas
NGROUPS_MAX works everywhere.
I'm not sure what the best course of action is. I think it still
probably
is eating the ephemeral 256kB stack penalty if NGROUPS_MAX is increased
to 65536.
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
