This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
libstc++ expectations for newlib's string.h
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: Eric Norum <eric dot norum at usask dot ca>, newlib at sources dot redhat dot com, libstdc++ at gcc dot gnu dot org
- Date: Fri, 23 Aug 2002 08:10:04 -0500
- Subject: libstc++ expectations for newlib's string.h
- Organization: OAR Corporation
- References: <50E9F2E2-B5F6-11D6-914D-00039366A118@usask.ca> <3D6549F6.196EB815@redhat.com>
Hi,
At Jeff Johnston's request, I am asking this on the libstdc++ mailing
list.
This problem arose when compiling the file bits/locale_facets.tcc with
gcc 3.2 on an embedded target (rtems) that uses newlib. newlib's
string.h
protects strdup() and some other routines with !__STRICT_ANSI__ yet they
seem to be assumed to be prototyped by C++ code and, in fact, are
prototyped
by the glibc string.h on RedHat 7.3 for C++ whether -ansi is specified
or not.
As noted at the bottom, Jeff believes that some of the tests in newlib
which are now on !__STRICT_ANSI__ should also be "or C++".
The full thread is below. We would appreciate it very much if someone
with more C++ expertise could provide guidance in what is expected
of the C library so we can fix newlib.
Thanks.
--joel
"J. Johnston" wrote:
>
> Eric Norum wrote:
> >
> > On Thursday, August 22, 2002, at 10:57 AM, Joel Sherrill
> > <joel@OARcorp.com> wrote:
> >
> > >
> > > Hi,
> > >
> > > Eric Norum ran across a problem some libstdc++-v3 code in gcc 3.2
> > > which compiles native but doesn't with newlib because of a minor
> > > difference in the two string.h implementations. I don't know whether
> > > this is a bug in newlib or not and wanted comments:
> > >
> > > The file:
> > >
> > > #include <string.h>
> > >
> > > int f(char *c1) {
> > > char *c;
> > > c=strdup(c1);
> > > }
> > >
> >
> > I'd just like to add that the problem shows up in the C++ header
> > bits/locale_facets.tcc which uses strdup. This makes it impossible to
> > compile some otherwise-valid C++ programs with -ansi and the newlib
> > headers.
> >
> > --
>
> The -ansi flag is defined as follows:
>
> `-ansi'
> In C mode, support all ANSI standard C programs. In C++ mode,
> remove GNU extensions that conflict with ISO C++.
>
> Thus, we should be testing for __cplusplus in addition to __STRICT_ANSI__. I would suggest
> that this matter be brought up on the libstdc++ forum to see what, if any, extensions
> newlib should be screening. The tests can be modified to be:
>
> #if !defined(__STRICT_ANSI__) || defined(__cplusplus)
>
> -- Jeff J.