[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 #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to cquike from comment #3)
> Thanks Adhemerval for your comments.
> 
> I agree that the documentation of getconf is not very clear on what the tool
> is supposed to deliver.
> 
> So I see three possible options for this isse:
> 
> 1. Keep the status quo. The current GNU getconf is not POSIX compliant with
> the command of the same name (although to be fair the documentation doesn't
> claim it is). The problem I see is that according to the documentation (man
> getconf) the value returned by getconf corresponds to a system configuration
> var as defined by pathconfig. However, pathconfig in Linux does not define
> _POSIX_PIPE_BUF.  It is simply not possible to get the value of
> _POSIX_PIPE_BUF using pathconfig. Interestingly, the Linux pathconfig
> manpage does actually refer to _POSIX_PIPE_BUF as the minimum value that can
> be used for a pipe buffer, clearly distinguishing it from _PC_PIPE_BUF,
> which is the value that applications might want to use get "more liberal
> values". So in that sense, at least under Linux, the behaviour of GNU
> version of getconf is inconsistent with the documentation (man getconf, man
> pathconfig).

Keep in mind that man-pages is not the canonical documentation.

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

So I do not agree that glibc getconf is not POSIX compliant with current POSIX 
requirements, neither that returning a value different than _PC_PIPE_BUF for
_POSIX_PIPE_BUF makes much sense, since it is the system obtained value the one 
that actually matters.

> 
> 2. Change the behaviour to follow the POSIX standard. As you pointed out
> this might be a bit tricky since it could break expectations from existing
> applications. However, it could be argued, that applications that request
> the value of _POSIX_PIPE_BUF do really care about getting the POSIX
> behaviour. They are basically requesting the minimum value of the pipe
> buffer for _any_ POSIX compliant implementation. So in that sense that
> variable is quite related to POSIX, otherwise there is no much point on
> asking for it rather than _PC_PIPE_BUF. In the case this change takes place,
> the documentation should clearly state the differences with previous
> behaviour under the section BUGS.

This does not make sense, if user issues 'getconf _POSIX_PIPE_BUF <path>'
and the system defined a minimum value that is larger than what POSIX defines
as the minimum value; the implementation does follow POSIX since
'conforming implementation shall provide a value at least this large or 
shall have no limit' [1].

I am still not really convinced that getconf should return any value defined
in limits.h, since for the users perspective what really matters is the 
implementation-defined one and whether it supports the minimal POSIX values
or not (for the limits.h a conforming implementation should support the
minimum set anyway).

> 
> 3. Similar to other GNU utilities, change the behaviour to either 1. or 2.
> depending on POSIXLY_CORRECT environmental variable being defined or not.

And I don't think this will make getconf more POSIX compliant, since POSIX
does not state POSIXLY_CORRECT as an affecting environment variable. 

> 
> Let me know your thoughts on that.


[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

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