public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Florian Weimer <fweimer@redhat.com>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: <nd@arm.com>, <libc-alpha@sourceware.org>
Subject: Re: [PATCH][BZ 21340] add support for POSIX_SPAWN_SETSID
Date: Tue, 04 Apr 2017 10:41:00 -0000	[thread overview]
Message-ID: <58E37848.8070407@arm.com> (raw)
In-Reply-To: <efbbf8fa-6489-2a00-8c57-c5ec5340554e@redhat.com>

On 04/04/17 10:38, Florian Weimer wrote:
> 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        0x80
>>>>
>>>
>>> Doesn'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.
> 

POSIX_* is reserved so there is no namespace issue,
but it can be conditional if glibc wants to be
strict about what is visible under different
posix versions (i don't think that is useful here).

  reply	other threads:[~2017-04-04 10:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 14:30 daurnimator
2017-04-03 18:39 ` Adhemerval Zanella
2017-04-03 19:12 ` Florian Weimer
2017-04-03 19:35   ` Adhemerval Zanella
2017-04-04  9:38     ` Florian Weimer
2017-04-04 10:41       ` Szabolcs Nagy [this message]
2017-04-04 11:05         ` Florian Weimer
2017-04-05  3:47 ` Daurnimator

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58E37848.8070407@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).