Re: Calling properly getpwuid_r

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Wed, Feb 13, 2013 at 1:43 PM, Roland McGrath <roland@hack.frob.com> wrote:
> Despite the poorly-chosen name, all the normative parts of the standard
> (POSIX.1-2008) describe _SC_GETPW_R_SIZE_MAX as "an initial value
> suggested" for the size of the buffer.  Only the informative part of the
> getpwnam_r/getpwuid_r descriptions say "... may return -1 if there is no
> hard limit on the size of the buffer needed".  That (non-normative) text is
> just wrong.  The example code in the same section shows the value being
> used as an initial size, not a size presumed large enough.  It's not a
> "system limit" at all.

I see it now:
~~~
"A call to sysconf(_SC_GETPW_R_SIZE_MAX) returns either -1 without
changing errno or an initial value suggested for the size of this
buffer."
~~~
Thanks, I'd missed this bit.

How frustrating for users.

> If sysconf returns -1 for _SC_GETPW_R_SIZE_MAX, then it's just completely
> useless to have the parameter at all.  It's allowed to do so just because
> that's the norm for all the things sysconf returns: the implementation can
> always just say, "I don't have anything helpful to say."
>
> As you said in that bugzilla report, get*_r can always return ERANGE and
> callers need to cope with that.  The purpose of _SC_GETPW_R_SIZE_MAX is to
> suggest a buffer size that is likely to be sufficient for a single cycle of
> allocation and call to satisfy the request, as an optimization for the
> common case.  Very large numbers of groups are not the common case.

Right, I'll close the BZ as RESOLVED/WONT FIX.

Cheers,
Carlos.