Subject: Re: need for end*ent()?
To: Jason Thorpe <>
From: Luke Mewburn <>
List: tech-security
Date: 09/15/2005 09:22:04
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 14, 2005 at 10:30:39AM -0700, Jason Thorpe wrote:
  | On Sep 14, 2005, at 10:23 AM, Jason Thorpe wrote:
  | >On Sep 14, 2005, at 1:10 AM, John Nemeth wrote:
  | >
  | >>     getpwent_r() isn't called by the library, just getgrnam() and
  | >>getpwnam_r() (it will be getgrnam_r() when I'm done).
  | >
  | >Please test it, but I thought that getgrnam() kept its own state, =20
  | >separate from the iterator API.
  | Hm, I just looked.
  | getgrnam_r() and getgrgid_r() use a local __grstate_files structure.  =
  | Thus, they do not require the "end" (they do it internally).
  | getgrent_r(), on the other hand, uses the global _files_state =20
  | instance.  That seems unfortunate (and hardly re-entrant).

IIRC, the rationale for this was that there isn't a "standardized"
getgrent_r() function (although there was some prior art in the
idea in other operating systems, although there may not have been
API or implementation consistency.)

If getgrent_r() used it's own state we'd then need to add a separate
API to allow rewinding ("endgrent") of a given getgrent_r() traversal,
which would require an opaque state argument passed between
setgrent_r()/getgrent_r()/endgrent_r(), which meant that getgrent_r()
would have a separate API on NetBSD to other platforms.

Note that getnetgrent() suffers a similar problem, even on systems
that have provided getnetgrent_r().  Which is unfortunate because
it means that the use of getnetgrent() within libc (e.g,
by getpwnam()) will move the "current pointer" that the end user
application was using.

[I think Jason & I may have discussed this privately when I was
working on the _r() rototill a few months ago]


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.1 (NetBSD)