Bug 137199

Created attachment 105803 [details]
Sample getgrent_r tester which demonstrates glibc bug.

That is not a glibc bug.  errno is not defined after getgrent_r
call.
man getgrent_r has:
RETURN VALUE
       On  success,  these  functions  return 0 and *gbufp is a pointer to the
       struct group.  On error, these functions  return  an  error  value  and
       *gbufp is NULL.
No words about errno being set.
POSIX doesn't cover getgrent_r, but getgrnam_r is similar enough and
covered by POSIX:
     ^[TSF] [Option Start] If successful, the getgrnam_r() function shall return zero; otherwise, an error number shall be
     returned to indicate the error. [Option End]

So, your testcase should be checking } else if (rc == ENOENT) { ... } else if (rc != ERANGE) { ... } else { ... }

Does this mean that it is a bug that getgrent_r clobbers errno without
warning in the ERANGE case?

errno is undefined after getgrent_r call.
See
http://www.opengroup.org/onlinepubs/009695399/functions/errno.html
The value of errno should only be examined when it is
indicated to be valid by a function's return value.
...
The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be
modified.
http://www.opengroup.org/onlinepubs/009695399/functions/getgrnam.html
doesn't indicate errno is not modified, nor claims errno is always set,
nor does have any return value that indicates errno is valid.
Therefore after you call getgrnam_r errno should not be examined.

getgrent_r is not covered by POSIX, but behaves in this regard like
getgrnam_r (and man getgrent_r describes this).

PERL bug report updated with your information:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137202