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

["cquike at arcor dot de" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #5 from cquike at arcor dot de ---

> 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]).

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.

> 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.