Web lists-archives.com

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




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