[Bug libc/5786] sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23

["carlos at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From carlos at codesourcery dot com  2008-02-23 00:28 -------
Interesting change, this is nice for programs that don't use libiberty's @file
support.

This change makes _SC_ARG_MAX variable over the life of the program, simialr to
_SC_OPEN_MAX (after a call to setrlimit with RLIMIT_NOFILE). The standard will
need to be changed, as it was changed for _SC_OPEN_MAX, to say "...may return
different values before and after a call to..."

We can immediately add support for calling getrlimit to compute the result of
sysconf(_SC_ARG_MAX), conditional on `__LINUX_KERNEL_VERSION >= 0x020617' (>=
2.6.23) i.e. the minimum kernel version supported by this glibc is 2.6.23.
Otherwise sysconf(_SC_ARM_MAX) must continue to return ARG_MAX, less than
accurate, but still correct.

The alternative is to add a new RLIMIT_* resource. Glibc may call getrlimit to
see if that is set (the kernel would take care to compute the right value),
return that for sysconf(_SC_ARG_MAX), otherwise ARG_MAX. This code would be
enabled if you were building against headers that defined the new RLIMIT_* resource.

What happens if you have less than 512 kB of RLIMIT_STACK? A quarter of that 
RLIMIT_STACK could be less than ARG_MAX. I would think it a kernel bug if it
doesn't honour providing ARG_MAX space.

Are you interested in helping implement this change in glibc?

Are you working with someone on the kernel side?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=5786

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.