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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |