public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Zack Weinberg" <zack@owlfolio.org>
To: "GNU libc development" <libc-alpha@sourceware.org>
Subject: Bad interaction between signal constants and -Wsign-conversion
Date: Mon, 27 Mar 2023 21:23:45 -0400	[thread overview]
Message-ID: <280b4afe-d080-4be5-a296-ec914b0b5439@app.fastmail.com> (raw)

This test program does something perfectly normal.  Well, it's cut down
from a program that does something perfectly normal.  SA_RESETHAND is
one of the bit flags intended to be used with the sa_flags field of
struct sigaction.

#include <signal.h>

struct sigaction sa = { 
  .sa_flags = SA_RESETHAND,
};

However ... on Linux, SA_RESETHAND happens to have the value 0x80000000,
and therefore, the type of that constant is 'unsigned int'.  And the
type of sa_flags is 'int'.  So if you compile this test program with
-Wconversion you get a warning:

$ gcc -fsyntax-only -Wconversion test.c
test.c:4:15: warning: signed conversion from ‘unsigned int’ to ‘int’
   changes value from ‘2147483648’ to ‘-2147483648’ [-Wsign-conversion]
    4 |  .sa_flags = SA_RESETHAND,
      |              ^~~~~~~~~~~~

This strikes me as a (minor) bug in our headers.  Given the ABI constraints
(this is a flags word passed to the kernel), I think the most straightforward
fix is probably to change the #define in bits/sigaction.h to

# define SA_RESETHAND ((int)0x80000000) /* Reset to SIG_DFL on entry to handler.  */

Anyone got a better idea?

zw

             reply	other threads:[~2023-03-28  1:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28  1:23 Zack Weinberg [this message]
2023-03-28  1:58 ` Paul Eggert
2023-03-28 14:03   ` Cyril Hrubis
2023-03-28 14:53     ` Florian Weimer
2023-03-28 15:04       ` Andreas Schwab
2023-03-28 18:50         ` Florian Weimer
2023-03-29  0:08 ` Alejandro Colomar
2023-03-30 13:45   ` Zack Weinberg
2023-03-30 13:59   ` Vincent Lefevre
2023-03-30 14:09     ` Alejandro Colomar
2023-03-31 15:31       ` Vincent Lefevre

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=280b4afe-d080-4be5-a296-ec914b0b5439@app.fastmail.com \
    --to=zack@owlfolio.org \
    --cc=libc-alpha@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).