This is the mail archive of the
mailing list for the newlib project.
Re: strnlen, strict ansi, newlib vs glibc
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Thomas Uhle <thomas dot uhle at eas dot iis dot fraunhofer dot de>, Luca Barbato <lu_zero at gentoo dot org>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Mon, 15 Sep 2014 13:55:16 -0500
- Subject: Re: strnlen, strict ansi, newlib vs glibc
- Authentication-results: sourceware.org; auth=none
- References: <53ECD579 dot 1030703 at oarcorp dot com> <54143F56 dot 9050408 at gentoo dot org> <1410793967 dot 1215 dot 745 dot camel at raymund7>
On 9/15/2014 10:12 AM, Thomas Uhle wrote:
> On Sat, 2014-09-13 at 14:57 +0200, Luca Barbato wrote:
>> 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?
>> Might be nice to add the support for _DEFAULT_SOURCE with the semantic
>> of not filter what is on by default notwithstanding the defines -std
>> might set.
>> It seems supported by glibc and musl so might be good to do as well.
> Hello Joel and Luca,
> I think that the current guard in newlib/libc/include/string.h:119
> #if !defined(__STRICT_ANSI__) || __XSI_VISIBLE >= 500
> should be simply replaced by the amended one
> #if !defined(__STRICT_ANSI__) || __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE >= 700
> to fix this issue.
If Corinna and/or Jeff is OK with this, then I have no issues as
long as -std=c99 trips the condition based on our cdefs.h. It looks
like it should.
I won't be able to try this for a few days.
Getting these guards just perfect is very tedious and error prone.
> Best regards,
> Thomas Uhle
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