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=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: [Bug] __wait_status_to_int() is expected to be a macro
To: cygwin@cygwin.com, denis.nikif@gmail.com
References: <CA+fF77nK6EUSWe_jxnQpEcOBiX-+uTxhh4vwT86swiybMcxB2A@mail.gmail.com> <0ec2d4a0-07e7-1c04-4efc-dbd0a21c077e@t-online.de> <636aef6d-c47f-ee0e-52c5-db4976452c18@redhat.com> <20180612084843.GO7851@calimero.vinschen.de>
From: Eric Blake <eblake@redhat.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>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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