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
