[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKCAbMig7io701gYXxDfY+x2p9_1AHQneSCV6aW+uw3VnExqZg@mail.gmail.com>
Date: Sat, 22 Apr 2017 19:49:04 -0400
From: Zack Weinberg <zackw@...ix.com>
To: Rich Felker <dalias@...c.org>
Cc: 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 7:47 PM, Rich Felker <dalias@...c.org> wrote:
> 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.
Makes sense.
zw
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.
