This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH] Add new getgrgid2(), getgrnam2() interfaces to glibc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]