wollman+austin-group@xxxxxx wrote, on 03 May 2007:
>
> >> Independently of this, I don't like #2. Normally, the _POSIX_* limits
> >> specify minimum maxima (or maximum minima, I suppose); this is
> >> something completely different. Compare NAME_MAX.
>
> > Nonsense. There is precedence for this kind of macro: _POSIX_VDISABLE.
>
> > And even if no, there is no reason whatsoever to not do it.
>
> You were claiming that adding this macro was for consistency. I
> pointed out that naming it _POSIX_something was not particularly
> consistent with the existing practice. _POSIX_VDISABLE is an oddball,
> currently the only one of its kind (the other _POSIX_* constants that
> correspond to _PC_* keys are all either limits or identify optional
> interfaces).
The _PC_* keys associated with options are not that much different
from _PC_VDISABLE. They all return some piece of information that
isn't a limit, it's just that the value returned for _PC_2_SYMLINKS,
_PC_ASYNC_IO, etc. is a yes/no indication whereas a wider range of
values is returned for _PC_VDISABLE.
Also, the values returned for _PC_REC_INCR_XFER_SIZE and
_PC_REC_XFER_ALIGN are not really "limits", despite being associated
with constants in <limits.h>.
--
Geoff Clare <g.clare@xxxxxx>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|