public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] tst_strstatus.c fails on Alpine
Date: Tue, 13 Jul 2021 11:25:54 +0200	[thread overview]
Message-ID: <YO1cIhIKgEPrApUC@yuki> (raw)
In-Reply-To: <YO1VaOB8nnMh6FT1@pevik>

Hi!
> Thanks for a hint. Indeed WIFSIGNALED(0xff) returns 1, thus tst_strstatus()
> returns signaled(status).
> 
> musl defines WIFSIGNALED() as:
> 
> #define WIFSIGNALED(s) (((s)&0xffff)-1U < 0xffu)
> 
> which returns 1.
> 
> Glibc defines __WIFSIGNALED() as:
> 
> #define __WIFSIGNALED(status) \
>   (((signed char) (((status) & 0x7f) + 1) >> 1) > 0)
> 
> which returns 0.
> 
> I wonder if it's a musl bug which we should report or {0x100, "invalid status
> 0xff"} test case is glibc specific and we should guard it with #ifdef __GLIBC__.

The process exit values are defined in the kernel ABI so I would say
that there shouldn't be any differencies between how these are handled
inside different libc implementation. That being said the musl version
is incorrect only for invalid values that will probably not happen in
practice. Glibc is simply more defensive in parsing and rejects invalid
conditions.

WIFSIGNALED() is supposed to return 1 only if process was killed by a
signal, which means that the upper byte of the status is ignored and the
lower byte has to look like:

7 6 5 4 3 2 1 0
x . . . . . . .
  ^
^ Termination signal
|
Core dumped flag

Also this value can't be set tio 0x7f since that means "stopped by
signal".

This is exaclty what glibc does since it masks the termination signal
number with 0x7f then adds 1, which would overlfow to 0x80 if the value
was 0x7f initially and end up being negative. The bitshift is there to
erase the +1 in a case we started with 0.

The musl libc returns 1 if the lower byte is non-zero and the upper byte
is zero, which depends on the fact that the upper byte is unused and
filled in zeroes when the process was killed by a signal and non-zero in
all other cases where the lower byte is non-zero. As long as we get only
valid status from wait() this is going to work fine.

To be honest I like the defensive parsing from libc more than the musl
variant but I'm not 100% sure if this is something that should be added
to musl as well.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2021-07-13  9:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-12 17:02 [LTP] tst_strstatus.c fails on Alpine Petr Vorel
2021-07-13  6:08 ` Jan Stancek
2021-07-13  7:50   ` Alexey Kodanev
2021-07-13  9:26     ` Petr Vorel
2021-07-13  8:57   ` Petr Vorel
2021-07-13  9:25     ` Cyril Hrubis [this message]
2021-07-13 10:24       ` Petr Vorel
2021-07-13 11:49         ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YO1cIhIKgEPrApUC@yuki \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox