Subject: Re: need for end*ent()?
To: Jason Thorpe <firstname.lastname@example.org>
From: Luke Mewburn <lukem@NetBSD.org>
Date: 09/15/2005 09:22:04
Content-Type: text/plain; charset=us-ascii
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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)
-----END PGP SIGNATURE-----