From: Joel Sherrill <joel@rtems.org>
To: C Howland <cc1964t@gmail.com>
Cc: Newlib <newlib@sourceware.org>
Subject: Re: Fw: [PATCH newlib 0/1] sys/signal.h needs sys/_intsup.h
Date: Thu, 26 Aug 2021 18:28:57 -0500 [thread overview]
Message-ID: <CAF9ehCWrrEhBjLgKQ3Gg3RTcJ3jcmRUXPS+koiwghgEbVkFJaA@mail.gmail.com> (raw)
In-Reply-To: <CANk6obTO4hr9keO1Ost0RtsgyGSp2HZ7KMkM1iMDp=D=sFea0w@mail.gmail.com>
On Wed, Aug 25, 2021 at 2:49 PM C Howland <cc1964t@gmail.com> wrote:
>
> ------------------------------
> > *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.
Yes. And after tearing into the code that didn't compile, I discovered
that #include <signal.h> does compile unless you add -ffreestanding.
When you add that, newlib's stdint.h does not get used. Instead gcc's
version does and that does not define __STDINT_EXP. This is gcc's
stdint.h:
====================================
#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
# undef __STDC_LIMIT_MACROS
# define __STDC_LIMIT_MACROS
# undef __STDC_CONSTANT_MACROS
# define __STDC_CONSTANT_MACROS
# endif
# include_next <stdint.h>
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif
====================================
We recently added this to sys/signal.h:
#if __STDINT_EXP(INT_MAX) > 0x7fff
#define SIG2STR_MAX (sizeof("RTMAX+") + sizeof("4294967295") - 1)
#else
#define SIG2STR_MAX (sizeof("RTMAX+") + sizeof("65535") - 1)
#endif
And -ffreestanding breaks that. I see two solutions:
(1) Add __STDINT_EXP to gcc's stdint-gcc.h
(2) Switch that #if to something else
I think something like this is an OK substitute works equivalently:
#if __SIZEOF_INT__ > 2
And toss my initial patch.
> 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>).
Yes. I should have been clearer. That's what I was wondering if was
a good test case.
> 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.
I was only thinking of ones called out in POSIX or C. Those often are listed
as single includes in the specifications of the methods.
--joel
> 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
> >
> >
> > ------------------------------
> >
next prev parent reply other threads:[~2021-08-26 23:29 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 ` Fw: [PATCH newlib 0/1] sys/signal.h needs sys/_intsup.h C Howland
2021-08-26 23:28 ` Joel Sherrill [this message]
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=CAF9ehCWrrEhBjLgKQ3Gg3RTcJ3jcmRUXPS+koiwghgEbVkFJaA@mail.gmail.com \
--to=joel@rtems.org \
--cc=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).