strnlen, strict ansi, newlib vs glibc

[Corinna Vinschen]

On Aug 14 10:57, Joel Sherrill wrote:
> 
> 
> On August 14, 2014 10:30:55 AM CDT, Luca Barbato <lu_zero@gentoo.org> wrote:
> >On 14/08/14 17:27, Joel Sherrill wrote:
> >> Hi
> >> 
> >> 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__
> 
> Thanks for the quick reply. 
> 
> How about I try to fix this based on what glibc and FreeBSD do?

I, for one, would be glad to get patches for newlib :}


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20140814/aaf4f57b/attachment.sig>