From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: getconf v2
Date: Fri, 15 Jun 2001 16:06:34 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDICEEOCEAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3028-Fri15Jun2001104224+0300-eliz@is.elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Shouldn't the output be just "undefined\n"?  That's what the Posix
> draft I have seems to indicate.  Or is there a new draft?

From my reading, "undefined\n" is only the mandated response for
undefined settings (ie getconf FOO); it doesn't specify what should
be printed if an invalid specification is used.
I would agree that this would be better handled by simply printing
undefined/-1 for any setting requested in that specification.

> Also, for this to work as Posix requires, I think we need an
> additional element in var_list[] which says something like this:
>
>   { "_POSIX_V6_ILP32_OFF32", 0, constant_var }
>
> because Posix says "getconf _POSIX_V6_ILP32_OFF32" should not print
> "undefined\n" or "-1\n" if "-v POSIX_V6_ILP32_OFF32" is supported.
> (The `0' in that line is arbitrary; any other suggestions?)

Posix' description of unistd.h also mentions this:

  _CS_POSIX_V6_ILP32_OFF32_CFLAGS
  If sysconf(_SC_V6_ILP32_OFF32) returns -1, the meaning of this value is
unspecified.
  Otherwise, this value is the set of initial options to be given to the cc
and c99 utilities to
  build an application using a programming model with 32-bit int, long,
pointer, and off_t
  types.

So wouldn't it be better to add _SC_V6_ILP32_OFF32 to sysconf, and
have getconf call sysconf()?
The same goes for most of these settings; wouldn't it be better to
extend pathconf() and sysconf() and simply have getconf call those?
We'd also need a confstr() function, I suppose.