Subject: Re: getpw*_r standards
To: Love <lha@stacken.kth.se>
From: Luke Mewburn <lukem@NetBSD.org>
List: current-users
Date: 04/12/2005 10:53:36
--7oqf3GZ7P06zs6V6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 11, 2005 at 01:28:56PM +0200, Love wrote:
  |=20
  | jnemeth@victoria.tc.ca (John Nemeth) writes:
  |=20
  | > but I believe the *_r functions were invented to make things work in a
  | > threaded world.
  |=20
  | _r functions are also very useful for libraries so they don't clobber
  | application's variables.
  |=20
  |=20
  | 	foo =3D getfoobyname("foo");
  | 	libcall();
  | 	printf("%s", foo->f_name);
  |=20
  | might not do what you expect if the libcall also calls getfoobyname.


What about the counterpoint, where calling
	bar =3D libcall();
	foo =3D getfoobyname_r("foo");
	printf("%s", bar->baz);
where getfoobyname_r() calls libcall().

The specific examples I'm thinking of relate to the passwd compat code,
even when using getpw*_r():

   (a)	"+@netgroup" uses getnetgrent(3) (et al), which would update
	the "netgroup cursor" for other callers of getnetgrent().

	Even implement Solaris' getnetgrent_r(3) would not help here,
	since getnetgrent_r(3) still updates the "netgroup cursor"
	and the caller of getpwnam_r(3) might not be expecting that.

   (b)	"+" uses getpwent_r(3), which updates the "passwd cursor"
	from dns/nis/(wherever passwd_compat points to)
	This may not be such a problem since I'm not sure what
	guarantees there are about the "passwd cursor" changing
	when interspersing getpwent(3) with getpw{ent,nam,uid}_r(3)
	or even getpw{nam,uid}(3).


I've been considering solutions to this, especially (a):

   (1)	Deprecate passwd compat.  It's kinda handy, but it adds
	complexity to the implementation of getpw*() as described above.

   (2)	Implement a new netgroup API that provides a "cursor cookie"
	(a la FILE * for stdio) to callers of
		setnetgrent
		loop calling getnetgrent
		endnetgrent
	so that internal libc functions such as getpw*(3) can do
	netgroup lookups without affecting end user applications
	use of netgroup lookups.

   (3)	Some other solution?


Thoughts?

Luke.

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

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

iD8DBQFCWxwQpBhtmn8zJHIRAjCTAJoDTcv+JlPImTsC0h+eavmZxaw+HgCgwetC
H/KD6Abbrev+gHvguE9GQHU=
=Ieee
-----END PGP SIGNATURE-----

--7oqf3GZ7P06zs6V6--