From owner-cvs-all  Mon Jan  6 11:12:59 2003
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id E24A437B401; Mon,  6 Jan 2003 11:12:57 -0800 (PST)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 494D243ED8; Mon,  6 Jan 2003 11:12:57 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1])
	by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h06JCuCJ089108
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK);
	Mon, 6 Jan 2003 14:12:56 -0500 (EST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h06JCuZ3089105;
	Mon, 6 Jan 2003 14:12:56 -0500 (EST)
	(envelope-from wollman)
Date: Mon, 6 Jan 2003 14:12:56 -0500 (EST)
From: Garrett Wollman <wollman@lcs.mit.edu>
Message-Id: <200301061912.h06JCuZ3089105@khavrinen.lcs.mit.edu>
To: obrien@FreeBSD.org
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/lib/libc/gen sysconf.c
In-Reply-To: <20030106043730.GA24930@dragon.nuxi.com>
References: <200209210214.g8L2E4Wc086892@freefall.freebsd.org>
	<20030106043730.GA24930@dragon.nuxi.com>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

<<On Sun, 5 Jan 2003 20:37:31 -0800, "David O'Brien" <obrien@FreeBSD.org> said:

> On a related note, why should 'LOGIN_NAME_MAX' be a run-time value?
> One of the most common use of it is "char foo[LOGIN_NAME_MAX];".

Such code is erroneous.  POSIX says quite clearly that
{LOGIN_NAME_MAX} is a run-time configuration parameter.  Programs
which are unable to cope with this ought not use the POSIX
parameter.  Bruce convinced me some moons ago that these parameters
should be left undefined in order to break buggy programs such as
these.

The only parameters which are guaranteed to be compile-time constants
are those listed in src/usr.bin/getconf/limits.gperf.

> Calling sysconf(3) in this context will not work.

Certainly it will:

#if LOGIN_NAME_MAX == 0
	char *buf;
	long buflen;

	buflen = sysconf(_SC_LOGIN_NAME_MAX);
	if (buflen < _POSIX_LOGIN_NAME_MAX) {
		/*
		 * Uh-oh.  Either we had an error, or there is no limit.
		 * Deal as best we can by assuming the POSIX minimum.
		 * If we were smarter, we would allocate however much space
		 * is actually needed for what we're planning to put in
		 * this buffer, but obrien's example did not give enough
		 * context.
		 */
		buflen = _POSIX_LOGIN_NAME_MAX;
	}
	buf = malloc((size_t)buflen);
#else
	char buf[LOGIN_NAME_MAX];
	long buflen = (long)sizeof buf;
#endif

	/*
	 * Do something with buf.
	 */

#if LOGIN_NAME_MAX == 0
	free(buf);
#endif

You could also write this as a run-time dynamic array, in those
dialects of C which support it:

	long maxlogname = sysconf(_SC_LOGIN_NAME_MAX);
	char buf[maxlogname < 1 ? _POSIX_LOGIN_NAME_MAX : (size_t)maxlogname];

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message