This is the mail archive of the
mailing list for the newlib project.
Re: strnlen, strict ansi, newlib vs glibc
- From: Luca Barbato <lu_zero at gentoo dot org>
- To: newlib at sourceware dot org
- Date: Thu, 14 Aug 2014 17:30:55 +0200
- Subject: Re: strnlen, strict ansi, newlib vs glibc
- Authentication-results: sourceware.org; auth=none
- References: <53ECD579 dot 1030703 at oarcorp dot com>
On 14/08/14 17:27, Joel Sherrill wrote:
> I have some native C++ code that I developed on CentOS and it
> has no warnings. Someone moved it to Cygwin and reported warnings
> for strnlen() not being prototyped. I investigated and the program did
> include string.h. I tried RTEMS tools and got the same as Cygwin
> since we have the same string.h from newlib.
> Investigating this, it appears that strnlen() is protected by
> __STRICT_ANSI__ on newlib and __USE_XOPEN2K8 on Linux.
> Command: g++ -Wall -std=c++0x -c strtest.cc
> This program is enough to reproduce the issue:
> #include <string.h>
> // size_t strnlen( const char *, size_t );
> size_t f( const char *str )
> return strnlen( str, 1000 );
> What do you all think?
It is a known issue with newlib headers.
They mistakenly assume __STRICT_ANSI__ as nothing but old-C.
using -std=c99 triggers the same kind of issues.
The common way to solve it is adding -U__STRICT_ANSI__