* Re: boost 1.67 with static_assert(!WIFSIGNALED(0x7f))
2018-08-10 15:59 ` Rich Felker
@ 2018-08-10 22:07 ` Rich Felker
0 siblings, 0 replies; 3+ messages in thread
From: Rich Felker @ 2018-08-10 22:07 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 3+ messages in thread