Mail Archives: djgpp-workers/2001/06/15/10:05:59
> 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.
- Raw text -