[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140717010830.GO17402@brightrain.aerifal.cx>
Date: Wed, 16 Jul 2014 21:08:30 -0400
From: Rich Felker <dalias@...c.org>
To: Brent Cook <busterb@...il.com>
Cc: musl@...ts.openwall.com, beck@...nbsd.org
Subject: Re: [PATCH] implement issetugid(2) (v4)
On Tue, Jul 15, 2014 at 03:29:01PM -0500, Brent Cook wrote:
> On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@...c.org> wrote:
>
> > On Tue, Jul 15, 2014 at 04:30:07PM +0000, Brent Cook wrote:
> >>> From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
> >> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
> >> [...]
> >
> > In this form, I think the code is now simple, clean, and correct. The
> > only thing I'd still like to check on is whether it's been proposed to
> > glibc and whether we can possibly get them on board with providing a
> > compatible function. While I think it's unlikely that there could be
> > any incompatibilities in such a simple function, I'd like to foster
> > the kind of cooperation on adding new interfaces like this that
> > unifies APIs rather than having each system go their own way and just
> > add things without consideration for furthering the goals of
> > compatibility and standardization.
>
> No, I have not contacted the glibc folks yet. I thought it would
> make sense to work out the details and discussion with just one C
> library first, and the ease of building/testing musl made it a
> no-brainer.
>
> Yes, without a doubt, this would be great to have in glibc too.
So far the response I got from the glibc side has been fairly
negative. Do you have any reaction to the claim that the BSD and
Solaris versions of this function are different/incompatible? As far
as I can tell they're the same.
I agree with them that the name is ugly and something of a misnomer,
but adding yet another function just to "fix" the name on platforms
where this already exists seems silly.
My leaning so far is to include issetugid even if the glibc folks
don't want to, since there seems to be no remotely portable way to
achieve the same thing without it. The suggestion of using getauxval
is much more low-level and tied to particular implementations (ELF or
ELF-like ones with aux vector or which emulate it), and I don't think
it's a reliable approach for applications linked to musl (since they
might be running on a 2.4 kernel). So even if software has to have a
fallback for glibc systems, I'd prefer that it use a libc-provided
issetugid() on musl so that we can provide a reliable answer rather
than asking the caller to make assumptions about the system.
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.
