[PATCH 0/1] Fix some warnings in the public headers

[Brian Inglis]

On 2021-04-11 04:31, R. Diez via Newlib wrote:
> I am experimenting with Newlib and I am not using option -isystem <path>, but the normal -I<path>, 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 <assert.h> 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 <assert.h> 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.]