From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14935 invoked by alias); 26 Feb 2008 14:33:54 -0000 Received: (qmail 14748 invoked by alias); 26 Feb 2008 14:33:09 -0000 Date: Tue, 26 Feb 2008 14:33:00 -0000 Message-ID: <20080226143309.14747.qmail@sourceware.org> From: "michael dot kerrisk at googlemail dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20080222153833.5786.michael.kerrisk@gmail.com> References: <20080222153833.5786.michael.kerrisk@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/5786] sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23 X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00118.txt.bz2 ------- Additional Comments From michael dot kerrisk at googlemail dot com 2008-02-26 14:33 ------- Subject: Re: sysconf(_SC_ARG_MAX) no longer accurate since Linux kernel 2.6.23 On 26 Feb 2008 13:57:17 -0000, carlos at codesourcery dot com wrote: > > ------- Additional Comments From carlos at codesourcery dot com 2008-02-26 13:57 ------- > I think we are in agreement here: > > A. It is worthwhile to recommend a change to POSIX.1, making note that ARG_MAX > is now variable. The exact wording of the change is up for discussion. > > Let me clarify the following issues: > > 1. The kernel must not lower the value of ARG_MAX in include/linux/limits.h. > This would break binary compatibility. I'm inclined to agree. > 2. I would propose that RLIMIT_ARG_MAX be a read and write value. How the kernel > implements this does not have to be discussed here. Sounds fine. The only possible object would be that we are changing the ABI that was put in place in 2.6.23. But I'm not sure how much that really matters. > 3. glibc would use getrlimit(RLIMIT_ARG_MAX, &lim); to determine if the > currently running kernel supports a variable size of argument and environ space. Sounds okay. > Notes: > - Without (2) and (3) userspace lacks a programmatic way to determine the [argv > + environ] space limit. Userspace could still probe the size by repeatedly > calling execve and looking for E2BIG errors, unfortunately there are performance > considerations. Agreed. -- 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.