--4CI+obvDyVe27XRB
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.
  |=20
  | Hm, I just looked.
  |=20
  | getgrnam_r() and getgrgid_r() use a local __grstate_files structure.  =
=20
  | Thus, they do not require the "end" (they do it internally).
  |=20
  | 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]


Cheers,
Luke.

--4CI+obvDyVe27XRB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDKLCcpBhtmn8zJHIRAhiWAKDRwqWhgeeOGDorYB+z01d1JqtonACfQ5MQ
OEzdaH7RPfdQc49aN6ocs3I=
=z5Xc
-----END PGP SIGNATURE-----

--4CI+obvDyVe27XRB--