[PATCH] linedit, deluser: use POSIX getpwent instead of getpwent_r

Rich Felker dalias at libc.org
Sat Feb 7 01:32:29 UTC 2015


On Thu, Feb 05, 2015 at 11:01:55PM +0100, Denys Vlasenko wrote:
> On Thu, Feb 5, 2015 at 9:52 PM, Rich Felker <dalias at libc.org> wrote:
> >> And musl will eventually be forced to implement getpwent_r()
> >> if it wants to be usable for more packages... so...
> >
> > getpwent_r makes no sense;
> 
> The _r part does not make sense; the fact that it avoids static storage
> _is_ useful.

Yes, but aside from implementations where the static storage cost is
high, the costs of getpwent_r (argument passing, possible logic for
enlarging buffer when result doesn't fit, etc.) seem worse to me. One
idea I'd like to toss out there -- don't know if you'll like it --
would it make sense to just use getpwent_r on __UCLIBC__ (which seems
to be the only target where it's a win) and otherwise just stick with
getpwent?

> > the _r functions are for thread-safe
> > versions of their corresponding legacy functions, but getpwent_r has
> > inherent global state -- the iterator. Whoever made it just wasn't
> > thinking. To make a correct interface like this the caller would need
> > to have an iterator object to pass to the function, but I can't see
> > much merit in inventing a new interface for this.
> 
> It doesn't matter that it makes no sense. It's glibc compat.
> If you want more programs rather than less to build
> against musl, you have to strive to be glibc-compatible where practical.

So far we haven't hit anything wanting to use it except busybox. I'm
all for compatibility, but it doesn't look easy to provide without
ugly code duplication or similar. We're in the middle of reworking
some of this code anyway to add alternate backend support, so I just
asked about how easy it would be to get getpwent_r too, but we didn't
see any obvious clean ways to do it. This is basically a consequence
of the way musl uses a dynamic buffer for the strings (line from the
file) so as not to impose an arbitrary line limit,

Rich


More information about the busybox mailing list