public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: C Howland <cc1964t@gmail.com>
To: newlib@sourceware.org
Subject: Re: Fw: [PATCH newlib 0/1] sys/signal.h needs sys/_intsup.h
Date: Wed, 25 Aug 2021 15:48:46 -0400	[thread overview]
Message-ID: <CANk6obTO4hr9keO1Ost0RtsgyGSp2HZ7KMkM1iMDp=D=sFea0w@mail.gmail.com> (raw)
In-Reply-To: <DM3P110MB052286CA15662F2A669975A29AC69@DM3P110MB0522.NAMP110.PROD.OUTLOOK.COM>

------------------------------
> *From:* Newlib <newlib-bounces+craig.howland=caci.com@sourceware.org> on
> behalf of Joel Sherrill <joel@rtems.org>
> *Sent:* Wednesday, August 25, 2021 3:12 PM
> *To:* newlib@sourceware.org <newlib@sourceware.org>
> *Subject:* [PATCH newlib 0/1] sys/signal.h needs sys/_intsup.h
>
>
>
> Hi
>
> The recent addition of the sig2str block of code for definitions and
> prototypes resulted in the following one line program not compiling
> for RTEMS targets:
>
> #include <sys/signal.h>
>
> Turned out that __STDINT_EXP used to conditionalize the definition
> of SIG2STR_MAX isn't defined unless <sys/_intsup.h> is included.
> I guess the test code got lucky.
>
> It's a simple patch that needed more background and investigation
> than code.
>
> Is it safe to assume that including each POSIX and Standard C Library file
> independently should compile? If so, I will file a ticket to at least at
> those to the RTEMS compile only tests like the ones we have that check
> a method can be used per the specific includes in the POSIX specification.
>
>      While I would think that #include on any "top level" include file
would have to compile on its own, sys/signal.h does not fall under that
umbrella.  That is, I don't think any valid use would call for
#include <sys/signal.h>
rather than
#include <signal.h>
So I think the real question is whether the latter works.
     By "top level" include I mean one that is intended to be directly
included by a user program, as opposed to indirectly included through
another include (as one would expect sys/signal.h to be nested to
<signal.h>).
     I'm not saying it is not a good idea that it can compile standalone,
but that I don't think it should be viewed as a requirement for every file
under include, especially most of them under sys.  There are some under sys
that are called to be directly included by user programs, specifically
sys/types.h, but the vast majority are not, intended to be nested from
other system includes.  So making test cases to specifically test for this
does not actually seem to be a good general idea for all include files, but
maybe only a subset.
     Aside from that general-approach thinking, something seems very
strange here.  sys/signal.h does include stdint.h and stdint.h does include
sys/_intsup.h.  So something about your test case failing seems like it has
to be wrong.  (I am not set up to compile with the current version, so I
can't easily check it.)
                 Craig

> Sorry this slipped through.
>
> --joel
>
> Joel Sherrill (1):
>   sys/signal.h: <sys/_intsup.h> is needed for __STDINT_EXP
>
>  newlib/libc/include/sys/signal.h | 4 ++++
>  1 file changed, 4 insertions(+)
>
> --
> 2.24.4
>
>
> ------------------------------
>

  parent reply	other threads:[~2021-08-25 19:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25 19:12 Joel Sherrill
2021-08-25 19:12 ` [PATCH newlib 1/1] sys/signal.h: <sys/_intsup.h> is needed for __STDINT_EXP Joel Sherrill
     [not found] ` <DM3P110MB052286CA15662F2A669975A29AC69@DM3P110MB0522.NAMP110.PROD.OUTLOOK.COM>
2021-08-25 19:48   ` C Howland [this message]
2021-08-26 23:28     ` Fw: [PATCH newlib 0/1] sys/signal.h needs sys/_intsup.h Joel Sherrill
2021-08-27 10:15       ` Corinna Vinschen
2021-08-27 13:47         ` Joel Sherrill
     [not found]           ` <DM3P110MB05221A305E6DAF45A77CCCAA9AC89@DM3P110MB0522.NAMP110.PROD.OUTLOOK.COM>
2021-08-27 15:12             ` C Howland
2021-08-27 16:16               ` Joel Sherrill
2021-08-27 17:52                 ` C Howland

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='CANk6obTO4hr9keO1Ost0RtsgyGSp2HZ7KMkM1iMDp=D=sFea0w@mail.gmail.com' \
    --to=cc1964t@gmail.com \
    --cc=newlib@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).