[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170422234729.GL17319@brightrain.aerifal.cx>
Date: Sat, 22 Apr 2017 19:47:29 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com, GNU C Library <libc-alpha@...rceware.org>
Subject: Re: [PATCH] add support for POSIX_SPAWN_SETSID
On Sat, Apr 22, 2017 at 07:43:01PM -0400, Zack Weinberg wrote:
> On Sat, Apr 22, 2017 at 7:19 PM, Rich Felker <dalias@...c.org> wrote:
> >> > #define POSIX_SPAWN_SETSIGMASK 8
> >> > #define POSIX_SPAWN_SETSCHEDPARAM 16
> >> > #define POSIX_SPAWN_SETSCHEDULER 32
> >> > +#define POSIX_SPAWN_SETSID 64
> >>
> >> This overlaps with the glibc value for POSIX_SPAWN_USEVFORK; while we
> >> don't implement it, we also don't want to have mismatched constant
> >> ABI.
> ....
> > Thanks for all your work on this! Based on the glibc patch review, I'm
> > changing the error condition from !=0 to <0, and of course changing
> > the flag value to 128 to match.
>
> May I suggest that musl include a note in its headers, explaining that
> bit 64 is reserved to avoid an ABI conflict with glibc? Then the next
> time there's an addition, there will be less confusion.
I was actually thinking of just adding POSIX_SPAWN_USEVFORK as a nop.
I think it will eventually be a nop on glibc too; maybe it already is
on Linux targets. Then we can have posix_spawnattr_setflags check
against all valid flags and return EINVAL if an unknown bit is set, so
that applications can runtime-probe for any future functionality
additions.
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.
