On Sat, Feb 7, 2015 at 2:32 AM, Rich Felker <[email protected]> wrote:
>> > 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,
How about this implementation?
int getpwent_r(struct passwd *pwbuf, char *buf, size_t buflen, struct
passwd **pwbufp)
{
char *line=0;
size_t size=0;
if (!f) f = fopen("/etc/passwd", "rbe");
if (!f) return 0;
*pwbufp = __getpwent_a(f, pwbuf, &line, &size);
if (!*pwbufp)
return 0; /* success (eof) */
if (size < buflen)
strcpy(buf, line);
free(line);
if (size < buflen)
return 0; /* success */
*pwbufp = 0;
errno = ERANGE;
return ERANGE;
}
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox