boost 1.67 with static_assert(!WIFSIGNALED(0x7f))

boost 1.67 with static_assert(!WIFSIGNALED(0x7f))

[Natanael Copa]

Hi,

Boost 1.67 introduced this compile time assert:
https://github.com/boostorg/process/commit/6625999765bbe24cc9e255bdeb284ea82d5f2258


> static_assert(!WIFEXITED(still_active) && !WIFSIGNALED(still_active), "Internal Error");

This was apparently introduced to prevent that WIFSIGNALED clashes with WIFSTOPPED.

On musl this results into:

/usr/include/boost/process/detail/posix/is_running.hpp:20:1: error: static assertion failed: Internal Error
 static_assert(!WIFEXITED(still_active) && !WIFSIGNALED(still_active), "Internal Error");
 ^~~~~~~~~~~~~

I wonder if the boost change is wrong or if musl WIFSIGNALED(0x7f) is buggy?

-nc

Re: boost 1.67 with static_assert(!WIFSIGNALED(0x7f))

[Rich Felker]

On Fri, Aug 10, 2018 at 05:45:33PM +0200, Natanael Copa wrote:
> Hi,
> 
> Boost 1.67 introduced this compile time assert:
> https://github.com/boostorg/process/commit/6625999765bbe24cc9e255bdeb284ea82d5f2258
> 
> 
> > static_assert(!WIFEXITED(still_active) && !WIFSIGNALED(still_active), "Internal Error");

As noted on #musl, I don't think this is even valid as a static
assertion, because POSIX imposes no requirement that these macros
produce constant expressions. As far as I can tell they could be
implemented as function calls.

> This was apparently introduced to prevent that WIFSIGNALED clashes with WIFSTOPPED.

This seems correct -- POSIX defines WIFSIGNALED only for when the
process terminated with a signal, which is of course mutually
exclusive with being stopped.

> On musl this results into:
> 
> /usr/include/boost/process/detail/posix/is_running.hpp:20:1: error: static assertion failed: Internal Error
>  static_assert(!WIFEXITED(still_active) && !WIFSIGNALED(still_active), "Internal Error");
>  ^~~~~~~~~~~~~
> 
> I wonder if the boost change is wrong or if musl WIFSIGNALED(0x7f) is buggy?

I'll have to look into whether 0x7f is a value that can actually be
seen. If so, one or both of the musl macros has a bug. If not, this
seems like a spurious failure based on incorrect assumptions in
boost. I'll follow up after doing some more research if nobody else
gets to it first.

Rich

Re: boost 1.67 with static_assert(!WIFSIGNALED(0x7f))

[Rich Felker]

On Fri, Aug 10, 2018 at 11:59:06AM -0400, Rich Felker wrote:
> On Fri, Aug 10, 2018 at 05:45:33PM +0200, Natanael Copa wrote:
> > Hi,
> > 
> > Boost 1.67 introduced this compile time assert:
> > https://github.com/boostorg/process/commit/6625999765bbe24cc9e255bdeb284ea82d5f2258
> > 
> > 
> > > static_assert(!WIFEXITED(still_active) && !WIFSIGNALED(still_active), "Internal Error");
> 
> As noted on #musl, I don't think this is even valid as a static
> assertion, because POSIX imposes no requirement that these macros
> produce constant expressions. As far as I can tell they could be
> implemented as function calls.
> 
> > This was apparently introduced to prevent that WIFSIGNALED clashes with WIFSTOPPED.
> 
> This seems correct -- POSIX defines WIFSIGNALED only for when the
> process terminated with a signal, which is of course mutually
> exclusive with being stopped.

OK, I think I've figured things out. They're not testing for 
WIFSIGNALED clashing with WIFSTOPPED; that would be:

static_assert(!(WIFEXITED(still_active) && WIFSIGNALED(still_active)), "Internal Error");

What they're testing for, based on the name still_active, seems to be
that they have a fake status value they can use that doesn't evaluate
true for either of these WIF* macros. And their assertion has
uncovered a bug in boost, because 127 _is a valid signal number_ (on
mips).

> > On musl this results into:
> > 
> > /usr/include/boost/process/detail/posix/is_running.hpp:20:1: error: static assertion failed: Internal Error
> >  static_assert(!WIFEXITED(still_active) && !WIFSIGNALED(still_active), "Internal Error");
> >  ^~~~~~~~~~~~~
> > 
> > I wonder if the boost change is wrong or if musl WIFSIGNALED(0x7f) is buggy?
> 
> I'll have to look into whether 0x7f is a value that can actually be
> seen. If so, one or both of the musl macros has a bug. If not, this
> seems like a spurious failure based on incorrect assumptions in
> boost. I'll follow up after doing some more research if nobody else
> gets to it first.

127 is a valid status that can be seen (only on mips though), and what
it means is that the process terminated by signal 127 (aka SIGRTMAX).
To summarize, the possible status values are:

	high 8 bits	low 8 bits	meaning

	0		nonzero		terminated by signal
					low 7 bits are signal number
					bit 7 is the core dump flag

	any		0		exited normally
					high bits are the exit code

	nonzero		127		stopped
					high bits are the signal that
					caused the stoppage

None of these overlap or clash. The musl definitions are correct for
all archs. The glibc ones might be wrong for mips, or they might have
a special version of the header for mips.

Boost just needs to find a new special value for still_active. I'm not
sure if there are any that will naturally work nice with the W* macros
(actually I think it's a really bad idea to depend on that; the W*
macros could freely be changed by the implementation as long as
they still produce the right results for status values produced by
wait* interfaces!) but there are plenty of combinations that can never
appear which boost could use for its reserved value instead *if* it
checks for the special value before passing it to the W* macros.

Rich