[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CWLP265MB41570C3A2B2E884E7659EB9CBC652@CWLP265MB4157.GBRP265.PROD.OUTLOOK.COM>
Date: Fri, 13 Sep 2024 11:45:13 +0000
From: Kate Deplaix <kit-ty-kate@...look.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] Increase NGROUPS_MAX from 32 to 1024
Hi,
Is there anything i can do to make a fix for this go forward?
Cheers,
Kate
________________________________
From: Laurent Bercot <ska-dietlibc@...rnet.org>
Sent: 11 April 2024 12:44
To: musl@...ts.openwall.com <musl@...ts.openwall.com>
Subject: Re: [musl] [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
Content of type "text/html" skipped
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.
