"Perry E. Metzger" <perry@piermont.com> writes:

> Klaus Klein <kleink@reziprozitaet.de> writes:
>> I see your point.  However, pw_dup(3) was supposed to support BSD auth
>> integration (which was to end up in libutil, and where it belongs
>> according to your reasoning), and as a supporting interface it seemed
>> to be suited there much better; I expect general use (outside the
>> domain of system-wide authentication management and the like), which
>> is was libc is for, to be negligible.
>
> Perhaps, but it is a general purpose interface, regardless of what it
> is used for. (It is also a very simple interface...)

Sigh.  I think you have a different concept of "general purpose" than
I do.  Few applications have a business in querying the password
database (the NetBSD tree is probably not a representative set to
sample from).  Furthermore, even fewer have a necessity to keep
multiple concurrent struct passwd around in their entirety.

As for "what it is used for", I have trouble to imagine it being used
for duplicating the data returned by getpwnam(3) et al.  It seems
unlikely to me that an application will fill in those data itself and
then use a system-provided library interface to do the duplication
work.

Now, with getpwnam_r(3) around the corner, the former use will cease
since the results are placed in caller-provided storage in their
entirety.  We should encourage use of portable interfaces.

Also, the finalized specification of getpwnam_r(3) has been around
since 1995; pw_dup(3) appeared in 2000 and, to the best of my
knowledge, hasn't spread much since-- precisely for the reasons given
above.  So far there is no gr_dup() at all, and adding one now has
similar prospects of success.


- Klaus