This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: C++ header compatibility patches
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: newlib at sources dot redhat dot com
- Date: Tue, 18 Jun 2002 15:06:52 -0700
- Subject: Re: C++ header compatibility patches
- Organization: Red Hat / San Francisco
- References: <20020618132432.101f2761.bkoz@redhat.com><3D0FADC8.B75128CF@redhat.com>
- Reply-to: bkoz at redhat dot com
> AFAICT you have hard-wired "on" the namespace code instead of "off".
> Am I missing something?
You are correct. It should be hard-wired to "off" before check-in. (#if
0 should be #if 1, or whatever.)
> There are a number of header files that use the extern "C" mechanism
> that you have chosen not to modify. Is this because you are only
> changing ANSI C header files?
Yes. I'm trying to do the smallest possible change.
> For example, you have not changed any of
> the libc/sys include files and there are some header files like
> malloc.h which you do not change in the main include directory. As
> well, you have moved some of the _BEGIN_STD_C statements from the
> location their corresponding extern "C" statements were.
extern "C" { nests, but
namespace std { extern "C" {
does not. I tried to make the movement as small as possible.
> If my
> assumption is correct and you only care about ANSI C variables and
> prototypes, that would explain it. Would there be a reason to still
> have the extern "C" statements covering the non-ANSI bits?
Yes. For C++ people who use the "C" headers. (Some, like pthreads.h, are
almost always used, for instance.)
Thanks,
benjamin