This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Calling properly getpwuid_r


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.

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.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]