Re: strnlen, strict ansi, newlib vs glibc

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

This type of change is always tricky. FreeBSD's string.h only had
__STRICT_ANSI__.  I read the glibc version and attempted to
translate their feature flags into the BSD style ones we have
from <sys/cdefs.h>.

There are a few methods I have no idea how to guard:

+ The block of Windows strcmpi and friends at the bottom
of the file.
+ strlwr() and strupr(). No idea where those originated.
+ _strerror_r() is another unknown origination.

Attached is try1. I expect there to be a few rounds of this.
I did build a complete sparc-rtems toolset and all RTEMS tests.

Please check what I did and offer corrections and improvements.
I tried to not rearrange the file. There is likely opportunity to
group methods with similar guards.

--joel

On 8/14/2014 10:57 AM, 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?
>
>> lu

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Attachment: string_h-try1.diff
Description: Text document