From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) by sourceware.org (Postfix) with ESMTPS id 5511B386EC52 for ; Sun, 11 Apr 2021 15:12:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5511B386EC52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([68.147.0.90]) by shaw.ca with ESMTP id VbkzlF9GVHmS3Vbl0lUcrT; Sun, 11 Apr 2021 09:12:14 -0600 X-Authority-Analysis: v=2.4 cv=MaypB7zf c=1 sm=1 tr=0 ts=607311ce a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=TImcKGuyeGIbufSLrCcA:9 a=QEXdDO2ut3YA:10 Reply-To: newlib@sourceware.org To: newlib@sourceware.org References: <20210411103126.714706-1-rdiezmail-newlib.ref@yahoo.de> <20210411103126.714706-1-rdiezmail-newlib@yahoo.de> From: Brian Inglis Organization: Systematic Software Subject: Re: [PATCH 0/1] Fix some warnings in the public headers Message-ID: <448d2470-44bb-b740-458f-adefe70127b9@SystematicSw.ab.ca> Date: Sun, 11 Apr 2021 09:12:12 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210411103126.714706-1-rdiezmail-newlib@yahoo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfMvbw0lQaNG4IthoJEnF2tiGN9FPBqOscWci+WIZ91/y8hMJ6HSxmSnMQF1aEt33AQLm0nNZLH3Z7AwlFKExa+vGOC9g9dQHAoq5DyutluEsuSCqphap 2sDNLKT6G5ZCmZohDe57VyzpoFKm5XhizGmV8xuK6DKBI/VRFvK75zmY7WUJNrQRS5xRMZFCfPClGcwWLBJaP16qNzgBjJepnSo= X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Sun, 11 Apr 2021 15:12:16 -0000 On 2021-04-11 04:31, R. Diez via Newlib wrote: > I am experimenting with Newlib and I am not using option -isystem , but the normal -I, so I get to see more compilation warnings than usual. > Maybe I am seeing more warnings because I am building in C++ mode. What do you mean by C++ mode? Perhaps you should be using C++ alternatives to these features and headers, or using them from a C wrapper module? > I have prepared a patch to fix those warnings, see below. Notes about the patch are: > About __ARM_FP: > The documentation for __ARM_FP states "Set if hardware floating-point is available", so I was getting an "is not defined, evaluates to 0 [-Wundef]" warning. > About _FORTIFY_SOURCE: > The GCC manual states "when the _FORTIFY_SOURCE macro is defined to a non-zero value", and that symbol was not defined in my build, so I was getting an "is not defined, evaluates to 0 [-Wundef]" warning. > About __assert_func(): > I was getting this warning: > redundant redeclaration of 'void __assert_func(const char*, int, const char*, const char*)' in same scope [-Wredundant-decls] > About __STDC_VERSION__: > I was getting an "is not defined, evaluates to 0 [-Wundef]" warning when compiling in C++ mode. > About _sig_func: > I was getting this warning: > warning: unnecessary parentheses in declaration of '_sig_func' [-Wparentheses] > R. Diez (1): > Fix some compilation warnings. > > newlib/libc/include/assert.h | 5 ++++- > newlib/libc/include/machine/ieeefp.h | 2 +- > newlib/libc/include/sys/features.h | 2 +- > newlib/libc/include/sys/reent.h | 4 ++-- > 4 files changed, 8 insertions(+), 5 deletions(-) Programs and builds really should always expect undefined macro variables, as much code only cares whether the variable is defined, and not the value - anything but 1 is just as good as 1. Extra parentheses are often necessary in macros around arguments, call a function and not a macro, ensure operation priority is correct, and as a defense against careless changes or definitions. The solution here is to suppress the warnings while you are including C headers in your C++ application code using: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wundef" #pragma GCC diagnostic ignored "-Wparentheses" #pragma GCC diagnostic ignored "-Wredundant-decls" /* optionally */ #include ... ... #pragma GCC diagnostic pop or the equivalent in your compiler. Beware of allowed redefinitions in assert.h(0p): "The header shall define the assert() macro. It refers to the macro NDEBUG which is not defined in the header. If NDEBUG is defined as a macro name before the inclusion of this header, the assert() macro shall be defined simply as: #define assert(ignore)((void) 0) Otherwise, the macro behaves as described in assert(). The assert() macro shall be redefined according to the current state of NDEBUG each time is included." In this file, __ASSERT_FUNC appears to be your first time flag, as it is only defined if NDEBUG is ever undefined and and the functions are needed, so you should be able to move the function declarations just before: # endif /* !__ASSERT_FUNC */ #endif /* !NDEBUG */ Why are you swapping the && conditions in the test for static_assert? If it's not causing a problem, don't touch it, there may well be good reasons for the order, that you are not testing. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]