From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id 06DA93857C67 for ; Wed, 25 Aug 2021 19:48:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 06DA93857C67 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qk1-x736.google.com with SMTP id e14so729466qkg.3 for ; Wed, 25 Aug 2021 12:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CvYImm2xF1PQrO9Ys0Jtja2Yf/C+2cpYbTRY8mn4h08=; b=Wfo8aqME+xHOhgrWghPlFaK4xJh+IsdNNrkoTOY5/QiXiEhaRKnRGaE5e7ywUAebLF 9paW+XlnNxbgcteBqZRGgYBGdmWgfHT918IqCS0dTUlRIYXl81FxyYus8hMYR22PIhU/ tRnPuKgcQqfKsMSt/eY7NHgN5ZDtFSy8+WxzUI84tMBoq9sOlK3FnYx3yA9fChRGybFa aqU7K9CDedxQm+aYFQ7aHig59UcvK2EyTUfnRxt5xi3zVU9acWmsD4q4g7IYL1FLVTj2 lCf+0yMAEP8VBbzpUenrDK1NCsbzr7ciTr8trODVcxnqiaB+ucc7/4AVkEJXM4AclVBT 6rPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CvYImm2xF1PQrO9Ys0Jtja2Yf/C+2cpYbTRY8mn4h08=; b=d6Ai6rmtDQUofMcsO8mGkurFZlqDg6RO5jAG6mCHMYhfKQx5Mluf5DAdNUcRmB4vW3 0r/jI9aE6b3tuhyJj2uIUHBOit0jHnPj4ylLKwdSMrj6AOwk9YXMcP3Qbwf7eHsbR64V Vg4jrYRO1m9ELiNjKYpyf/Ds/4NqrudGu+7sOwmXO422e4LCRrRVTLoeokpPSJXlCcHy +kFx2mHAmFOAQSQ2QYKAEEpIoMOjv+BYE3nv6JzS6Frnayk4e2BRoPRx9rw92PdCl+2t 6JdITMKMoEoB+pHsv5q+S1z3YgzmOz5Ci0pNxHk/yjY/Dcrotaf0wQeNooVislX1Q0Py S0fA== X-Gm-Message-State: AOAM531RZPjLZSr/6FbECHGuj1LUALrE0ni3/vhW0u1eDD3u8UuDxHD9 zMO+anZJz77n/09xdLrrJYCUEBSNByBe7/AHHUqurWykYw== X-Google-Smtp-Source: ABdhPJwK14dbScSiHz/nmjlBDEPAITEoYCTwSwEHSHuUrX+PMLla6wXTI1k6/OQRkQROkAPfYZ8eAFQ6dIaqUCmlc/k= X-Received: by 2002:ae9:ebd5:: with SMTP id b204mr198415qkg.83.1629920937428; Wed, 25 Aug 2021 12:48:57 -0700 (PDT) MIME-Version: 1.0 References: <20210825191245.30049-1-joel@rtems.org> In-Reply-To: From: C Howland Date: Wed, 25 Aug 2021 15:48:46 -0400 Message-ID: Subject: Re: Fw: [PATCH newlib 0/1] sys/signal.h needs sys/_intsup.h To: newlib@sourceware.org X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 19:49:00 -0000 ------------------------------ > *From:* Newlib on > behalf of Joel Sherrill > *Sent:* Wednesday, August 25, 2021 3:12 PM > *To:* 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 > > Turned out that __STDINT_EXP used to conditionalize the definition > of SIG2STR_MAX isn't defined unless 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 rather than #include 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 ). 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: is needed for __STDINT_EXP > > newlib/libc/include/sys/signal.h | 4 ++++ > 1 file changed, 4 insertions(+) > > -- > 2.24.4 > > > ------------------------------ >