Date: Sat, 19 Jul 2014 16:07:25 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Cc: beck@...nbsd.org, Brent Cook <busterb@...il.com> Subject: Re: [PATCH] implement issetugid(2) (v4) On Wed, Jul 16, 2014 at 09:33:11PM -0500, Brent Cook wrote: > > 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. > > OK, thanks for considering it. Based on the discussion so far, I'm going to commit it. I'm moving the file to a different location though (probably src/misc unless anyone has a better idea) since the aim (not 100% followed right now) is to keep the "standard" directories reserved for either standard functions or nonstandard extensions that clearly belong in the same functional group (like stdio or thread extensions). Having issetugid under unistd seems more like a BSD implementation detail (doing it as a syscall) than a logical grouping. Of course keeping the prototype in unistd.h makes sense just because we shouldn't break apps' expectations for where to get it. The other thing I'd like to do is summarize the discussions of why it makes sense for musl to adopt this as a commit message. The message in your email is nice as an argument from the BSD side, but I'd also like to address why it (and other remarks) have been convincing. 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.