X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=oDM10uUUmyC9EUlV
	URwITQKxMfaRO2oir10rQZawOhDowe8piwDDm2X42o1qg7emhOIujxRXqyvmpl7h
	axlT1QBLkwyoitUEiJNmNTAWEnLOMETlll4TiFeARyW087C9YRMJxHk684aNs8Rm
	fRc+hREaSaGeXW+x2s8AabEhou8=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=LFOBaBfn2PcqreYjbtQIOf
	MWfZg=; b=GC6siz9MYapwGDLPM0Qg5i7pf9c253GxWtj4+dWsCWYsQJt/1wQtT1
	6AATmgep59peL7Oxnt0PCTQRPLmUtCTTE7YCzkCrsC8n5jo4X8CQmPP0ZiU7AgMo
	LsqHAI1tiho/vW8zLHfaQdN22apHuE8pBxICso6vSf+eS3S6M1KHs=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=principal, boosts
X-HELO:	mx1.redhat.com
Subject:	Re: [Bug] __wait_status_to_int() is expected to be a macro
To:	cygwin AT cygwin DOT com, denis DOT nikif AT gmail DOT com
References:	<CA+fF77nK6EUSWe_jxnQpEcOBiX-+uTxhh4vwT86swiybMcxB2A AT mail DOT gmail DOT com> <0ec2d4a0-07e7-1c04-4efc-dbd0a21c077e AT t-online DOT de> <636aef6d-c47f-ee0e-52c5-db4976452c18 AT redhat DOT com> <20180612084843 DOT GO7851 AT calimero DOT vinschen DOT de>
From:	Eric Blake <eblake AT redhat DOT com>
Message-ID:	<95cbcdf4-909a-e7b6-b983-5ca82a25ffab@redhat.com>
Date:	Tue, 12 Jun 2018 06:45:43 -0500
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version:	1.0
In-Reply-To:	<20180612084843.GO7851@calimero.vinschen.de>
X-IsSubscribed:	yes

On 06/12/2018 03:48 AM, Corinna Vinschen wrote:
> On Jun  8 12:43, Eric Blake wrote:
>> On 06/08/2018 12:26 PM, Hans-Bernhard Bröker wrote:
>>> Am 08.06.2018 um 17:16 schrieb Denis Nikiforov:
>>>> /usr/include/boost/process/detail/posix/is_running.hpp:18:1: error:
>>>> non-constant condition for static assertion
>>>>    static_assert(!WIFEXITED(still_active), "Internal Error");
>>>>    ^~~~~~~~~~~~~
>>>>
>>>> __wait_status_to_int must be a macros but it's redefined as a function.
> 
> I don't know the surrounding code, but in how for does this make
> sense at all?  This expression is never static, afaics:
> 
>    int status;
>    wait (&status);
>    WIFEXITED(status);

That's the typical use.  But the context in boost's is_running.hpp is:

constexpr int still_active = 0x7F;
static_assert(!WIFEXITED(still_active), "Internal Error");

which means boost _is_ trying to assert that a particular process status 
value will be interpreted as a non-exited status.  But that in itself is 
non-portable: process status has traditionally been 16 bits, but there 
are some platforms which do '(abnormal<<8)|normal' and some platforms 
which do '(normal<<8)|abnormal' when combining the 8 bits of normal exit 
status with the 8 bits for reporting death by signal.  You _cannot_ 
guarantee whether the constant value 0x7F is the 'normal' status or the 
'abnormal' status half of the wait() result.  That's WHY the WIFEXITED() 
macro and friends exist - to abstract away _which_ bits are important to 
which situation.  So anyone ever trying to assert that a _particular_ 
value has a given meaning, without using the macros (other than the 
special case of '0' happening to work for WIFEXITED() on all platforms, 
regardless of which way the two halves are pasted together), is buggy.

What's more, I can't see any other use of 'still_active' in 
is_running.hpp, nor any other use of process status that does NOT use 
the portable WIFEXITED() macro and friends, so I have no idea why boost 
is bothering to make a non-portable static assertion in the first place.

But as I don't use boost on a regular basis, I'm not in the best 
position to file this as an upstream bug to that project.

> 
> The sense of the above expression with a constant "still_active" is
> somehow beyond me.
> 
> And this has nothing to do with macro vs. inline function, nor ...

Yeah, if it were a runtime value, then it makes no sense; the fact that 
boost really is trying to do a static assertion on a compile-time 
constant is why compilation failed, but that's because boost is being 
stupid for doing something that is not portable.

> But, assuming I'm completely off-track above and a macro is really
> desired:
> 
> Defining __wait_status_to_int as function is C++-specific.  I don't think
> this is really required.  A quick test implies the C macro definition in
> sys/wait.h is sufficent for C++ as well.

Yes, I think you're right on that front.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -