[Bug libc/29147] getconf: Wrong values for symbolic constants defined in limits.h

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29147

--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to cquike from comment #5)
> > POSIX standard also defines that for getconf each configuration variable 
> > shall be determined as if it were obtained by calling the function from
> > which it is defined to be available (either fpathconf, sysconf, or confstr)
> > [1].
> > 
> > And for fpathconf, POSIX only defines a handfull of symbolic constants an 
> > implementation should support (which _POSIX_PIPE_BUF is not listed).  Also 
> > for _POSIX_PIPE_BUF, it means the 'Maximum number of bytes that is
> > guaranteed 
> > to be atomic when writing to a pipe'.
> > 
> 
> Maybe I am interpreting it wrongly, but I see that getconf provides
> variables that are defined via fpathconf, sysconf, confstr _or_ limits.h.
> The third bullet under "system_var" says literally "The names of the
> symbolic constants listed under the headings ``Maximum Values'' and
> ``Minimum Values'' in the description of the <limits.h> header" ([1]). And
> indeed _POSIX_PIPE_BUF is listed under "Minimum values" in the description
> of limits.h ([3]) and not under fpathconf, as you correctly mention ([2]).

Another issue is POSIX is not clear how the 'Maximum' and 'Minimum' values
should
be obtained, but getting the POSIX defined values seems rational.

> 
> In fact, consider the output of this small program:
> 
> #include <limits.h>
> #include <stdio.h>
> 
> int main()
> {
>   printf("_POSIX_PIPE_BUF: %d\n", _POSIX_PIPE_BUF);
> }
> 
> $ ./a.out
> _POSIX_PIPE_BUF: 512
> 
> and the output of getconf:
> 
> $ getconf _POSIX_PIPE_BUF /
> 4096
> 
> which are, in my opinion, in contradiction. By the way, it also highlights
> yet another problem with the current implementation: for _POSIX_PIPE_BUF it
> shouldn´t be needed to provide a path, since it is a symbolic constant.
> 
> 
> > for the users perspective what really matters is the 
> > implementation-defined
> 
> For most applications I agree with you. That means that POSIX conformant
> applications applications are most interested on querying fpathconf(fd,
> _PC_PIPE_BUF) or the equivalent getconf PIPE_BUF /path . However _strictly_
> conformant applications ([4]) should not rely on the implementation
> supporting a limit larger than _POSIX_PIPE_BUF. It is for those applications
> where this constant might be useful.

Right, it seems that other system do return the limits.h value (Solaris 11, AIX
7.2,
and MacOSX) so it seems that it would be good to have the same behavior.

> 
> > And I don't think this will make getconf more POSIX compliant, since POSIX
> > does not state POSIXLY_CORRECT as an affecting environment variable. 
> 
> Yes, you are right.
> 
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getconf.html
> [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html
> [3] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
> [4]
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.
> html#tag_02_02_01

-- 
You are receiving this mail because:
You are on the CC list for the bug.