From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70302 invoked by alias); 4 Apr 2017 09:38:49 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 70283 invoked by uid 89); 4 Apr 2017 09:38:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=wondering X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1B2CD61D02 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1B2CD61D02 Subject: Re: [PATCH][BZ 21340] add support for POSIX_SPAWN_SETSID To: Adhemerval Zanella References: <20170401142954.23142-1-quae@daurnimator.com> Cc: libc-alpha@sourceware.org From: Florian Weimer Message-ID: Date: Tue, 04 Apr 2017 09:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00042.txt.bz2 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. >> 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