From owner-freebsd-bugs  Mon Oct 14 01:50:06 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA13963
          for bugs-outgoing; Mon, 14 Oct 1996 01:50:06 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA13957;
          Mon, 14 Oct 1996 01:50:03 -0700 (PDT)
Date: Mon, 14 Oct 1996 01:50:03 -0700 (PDT)
Message-Id: <199610140850.BAA13957@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: misc/1791: syslimits.h does not allow overriding default value of ARG_MAX
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR misc/1791; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.org, tegge@itea.ntnu.no
Cc:  Subject: Re: misc/1791: syslimits.h does not allow overriding default value of ARG_MAX
Date: Mon, 14 Oct 1996 18:37:04 +1000

 >	It is not possible to specify an alternative value of ARG_MAX
 >	in the kernel config file, since /usr/src/sys/sys/syslimits.h 
 >	defines ARG_MAX even if it was defined.
 
 This isn't a bug.  Defining ARG_MAX in <limits.h> advertises to
 applications that ARG_MAX is a constant with the given value.  The
 only correct way to change it is to change the header and recompile
 all applications that depend on it (ps, xargs and who-knows-what
 else).
 
 The best way to fix the problem is to remove the definition of
 ARG_MAX from <limits.h> and then fix everything that (bogusly)
 depends on it.  Non-bogus dependencies on it look like this:
 
 #ifdef ARG_MAX
 	char buf[ARG_MAX];
 #else
 	long arg_max;
 	char *buf;
 
 	arg_max = sysconf(_SC_ARG_MAX);
 	if (arg_max == -1)
 		barf("sysconf");
 	st_arg_max = (size_t)arg_max;
 	if (st_arg_max != arg_max);
 		barf("unrepresentable arg_max");
 	buf = malloc(st_arg_max);
 	if (buf == NULL)
 		barf("malloc");
 #endif
 
 The kernel should use some other name for ARG_MAX to avoid confusion.
 
 I have fixed most the corresponding problems for OPEN_MAX and CHILD_MAX.
 They are now named PROC0_RLIMIT_NOFILE and PROC0_RLIMIT_NPROC in my
 kernel sources.
 
 Bruce