This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 04/03/2017 09:35 PM, Adhemerval Zanella wrote:
On 03/04/2017 16:12, Florian Weimer wrote:On 04/01/2017 04:29 PM, daurnimator wrote:diff --git a/posix/spawn.h b/posix/spawn.h index 36e3867e17..8d2ace1b87 100644 --- a/posix/spawn.h +++ b/posix/spawn.h @@ -60,6 +60,7 @@ typedef struct #ifdef __USE_GNU # define POSIX_SPAWN_USEVFORK 0x40 #endif +#define POSIX_SPAWN_SETSID 0x80Doesn't this add the flag to past POSIX versions?I do not think this is an issue since afaik POSIX does not state any constraint regarding the flags values [1]. For instance, the example library implementation uses spawn as example and just use constant different than glibc [2].
Sorry, this is not what I meant. I was wondering if it was acceptable, from a namespace point of view, to define the constant unconditionally, or if we have to use a feature test macro here.
I wonder if we should add a new symbol version for posix_spawnattr_setflags, so that applications which do not perform error checking for the function call fail in a predictable manner.I do not follow, which semantic difference are you proposing for posix_spawnattr_setflags that are not covered currently?
I'm worried about applications which ignore the error return value from posix_spawnattr_setflags, use POSIX_SPAWN_SETSID, and accidentally spawn processes with the wrong flags.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |