[Bug] __wait_status_to_int() is expected to be a macro

Eric Blake eblake@redhat.com
Fri Jun 8 17:43:00 GMT 2018


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.
> 
> It must?  Says who, based on what standard document?
> 
> For starters, nobody gets to make any such claims about 
> __wait_status_to_int(), because that's an internal implementation detail 
> of Cygwin.  If at all, such a claim might be made about WIFEXITED(), 
> which is a POSIX standard element.  But POSIX makes no such requirement, 
> as far as I could see on short examination.

POSIX requires:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html#tag_13_71

"The <sys/wait.h> header shall define the following macros for analysis 
of process status values:

WEXITSTATUS
     Return exit status.
WIFCONTINUED
     [XSI] [Option Start] True if child has been continued. [Option End]
WIFEXITED
     True if child exited normally.
..."

and:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitpid.html

"Regardless of its value, this information may be interpreted using the 
following macros, which are defined in <sys/wait.h> and evaluate to 
integral expressions; the stat_val argument is the integer value pointed 
to by stat_loc.

WIFEXITED(stat_val)
     Evaluates to a non-zero value if status was returned for a child 
process that terminated normally.
WEXITSTATUS(stat_val)"


Nothing in that wording requires WIFEXITED(foo) to be a compile-time 
constant if foo is also a compile-time constant, so on that grounds, 
Boost is buggy for trying to assume that WIFEXITED(constant) can be used 
in a static_assert().  On the other hand, the implementation of 
WIFEXITED() is more like Linux if it DOES result in a compile-time 
constant when used on a compile-time constant argument; so in that 
regards, it would ALSO be worth patching Cygwin, whether or not the 
Boost portability bug is fixed.

-- 
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



More information about the Cygwin mailing list