This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH,HURD]: Update posix_opt.h
> From what I understand of the standard, 0 precisely means that:
There are kinds of option macros with different rules. You are conflating
the two kinds into the first set of rules. I was thinking that the second
set of rules applies to both flavors, which in fact was the case at least
Now I'm looking at 1003.1-2008. The rules you cited indeed do apply to the
"Constants for Options and Option Groups" (for which you call sysconf to
test at runtime). Below that in the same section (under <unistd.h>), see
"Execution-Time Symbolic Constants" for the rules worded slightly
differently (it's for these ones that you call pathconf). It's not as
clear as it should be, but I still read the latter rules as meaning that
set to 0 means it's a compile-time constant 0 rather than depending on a
runtime pathconf check. In fact--and most confusingly--the wording there
seems to indicate that #define to 0 (defined foo && foo != -1) means the
feature is always available, and only #define to -1 means it's always
The long comment in unistd.h accurately describes the distinction as it's
specified in 1003.1-1996, which really is only sysconf vs pathconf.
Since then, multiple things have changed in the standard.
The first category is no longer described as being queried by sysconf
(which was implied by the text and its references in 1003.1-1996, and hence
our unistd.h comment says so explicitly). Instead, the first category is
addressed more explicitly in the section you cited (2.1.6), where it
mentions both sysconf and pathconf.
_POSIX_VDISABLE is no longer optional at all, it's just a macro that has to
be defined to some constant you can use as cc_t, not one of the "option"
_POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC have moved from the second
category to the first. I'm not sure what to make of that, if anything.
To me, they fit more naturally in the second set. But whatever.
So, your changes make sense for all those in the first set. But they don't
make sense for the second set, unless they change the standard's wording to
match 2.1.6 as to the meaning of #define to 0. The only ones there now are
_POSIX_ASYNC_IO, _POSIX_PRIO_IO, and _POSIX_SYNC_IO.
If what glibc will now provide follows the 1003.1-2008 rules rather than
the 1003.1-1996 rules, I would like to see the unistd.h comment changed to
reflect the semantics of the values before we change any posix_opt.h settings.
> I don't see which change you'd like to see in the comments. The way I
> understood was the meaning of the option, so a question mark makes
I was referring to the "You must query ..." comment.
> I have seen places assuming that such macros are defined and just check
> against -1. It wasn't these macros in particular, however.
Ok. I guess -1 is always fine for the API-present stuff, since a new
library where you could actually succeed in linking in such API calls would
have a new header to match. That is, if we assume applications are using
the 1003.1-2008 rules with #if _POSIX_FOO != -1. OTOH, the 1003.1-1996
wording just says "if defined" for the first set, meaning that applications
using those rules might use #ifdef _POSIX_FOO instead, for which -1 yields
the wrong result. Defensive code would use defined foo && foo != -1 to
handle either set of rules correctly. But we can't always assume that.