This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strnlen, strict ansi, newlib vs glibc



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?

>lu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]