This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH] Add new getgrgid2(), getgrnam2() interfaces to glibc
- From: Roland McGrath <roland at redhat dot com>
- To: Petr Baudis <pasky at suse dot cz>
- Cc: libc-alpha at sourceware dot org, rhafer at novell dot com, sgallagh at redhat dot com
- Date: Mon, 18 Oct 2010 17:39:56 -0700 (PDT)
- Subject: Re: [RFC][PATCH] Add new getgrgid2(), getgrnam2() interfaces to glibc
- References: <20101018234247.GI8806@machine.or.cz>
I have a personal aversion to all names like foobar2 or foobar3.
They are just not sensible names to use.
I don't see any motivation sufficient to add any new interfaces that are
not thread-safe. Why add somethingnew_r and somethingnew both, instead of
just a single new thing that has the property of thread-safety, which we
would say a priori is desireable for anything we invent this millenium?
In the grand scheme of things, it doesn't seem like a significant
imposition or performance issue to simply always use malloc'd strings for
the group name ans password (perhaps allow NULL in place of "" for an empty
group password, since that is common). Without the membership list, that
is the only variable-length part of what's returned.
So it could be something like:
int grplookup (const char *name, gid_t gid, struct group *result);
If NAME is non-null, the lookup is by name and GID is ignored.
If NAME is null, the lookup is by GID. The RESULT fields are
filled, using malloc'd pointers for the strings.
Just the simple getgidbyname seems fine enough to me too. There is no real
reason to have a constraint that the user-visible libc API must look like
the internal NSS module API for the backend hooks.
All that said, I really don't have any strong opinions about this at all.
Thanks,
Roland