This is the mail archive of the glibc-bugs@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]

[Bug nscd/15139] getpwuid_r does not return ERANGE consistently


http://sourceware.org/bugzilla/show_bug.cgi?id=15139

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> 2013-02-13 18:58:32 UTC ---
(In reply to comment #2)
> Thanks Carlos for analysis. I will talk with Sigar team to take your advice
> into account.
> 
> Still, I don't understand why the extracted test case with 1024 sized buffer
> works whereas the same code in Sigar doesn't. Or is it why you say "the
> function is allowed to return ERANGE at *any* time"?

You are assuming that the implementation requires a deterministic amount of
buffer in all conditions and that is unfortunately not true. I can't currently
guarantee that, all I can guarantee is that if the implementation requires more
buffer it will return ERANGE and you have to start the query all over again.

As it turns out POSIX.1-2008 says:
"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."

Therefore, despite the name "SIZE_MAX" it is actually a suggested initial value
for the buffer e.g. a minimum, and not a maximum.

I'm closing this as RESOLVED/INVALID since the standard says it's an initial
suggested value, and as Roland points out "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."

Thus the fix is entirely in Sigar to increase the buffer when ERANGE is
returned. Taking care not to introduce a DoS by increasing the buffer without
bounds.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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