[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251029172718.GP1827@brightrain.aerifal.cx>
Date: Wed, 29 Oct 2025 13:27:18 -0400
From: Rich Felker <dalias@...c.org>
To: Sebastien Marie <semarie@...ouay.eu.org>
Cc: musl@...ts.openwall.com
Subject: Re: about getpwent functions family
On Wed, Oct 29, 2025 at 08:44:24AM +0100, Sebastien Marie wrote:
> Hi,
>
> I am using alpine linux (which is using musl libc) and I am trying to
> build xen-api [1].
>
> xen-api is using getpwent_r (and getspent_r but let's focus on
> getpwent_r) function in unixpwd [2], a simple C library with OCaml
> bindings to support updating Unix account passwords in /etc/passwd and
> /etc/shadow.
>
> I am looking for rational or previous discussion about inclusion or not
> of such GNU extension functions in musl.
>
> fgetpwent and putpwent, which are also GNU extension, are already
> present.
>
> If there is no objection, I would look to provide patches for adding
> getpwent_r() and/or fgetpwent_r() (and {,f}getspent_r counterpart).
The reason there's no getpwent_r is that it does nothing to solve the
problem with normal getpwent: it's still non-thread-safe and
non-library-safe, because it iterator it uses is global state. All it
does is give you the strictly-worse klunky buffer handling, but still
with the need to use locking.
fgetpwent_r solves this, but it doesn't abstract the source of
records. There's no interface to setup or tear down iterators; it
works directly on FILE* and only supports reading records from a
classic passwd file.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
