C++ header compatibility patches
J. Johnston
jjohnstn@redhat.com
Wed Jun 19 10:05:00 GMT 2002
Benjamin Kosnik wrote:
>
> > 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.)
I imagine you might want to key this off a new define. In the future,
we could trigger this define via configuration (either config.h or
via a dynamic header file).
>
> > 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.
>
Ok.
> > 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.)
>
If you change the patch with regards to the setting of _BEGIN_STD_C and _END_STD_C
and verify that newlib builds with the patch, you may apply it or resubmit it here and I
will apply it for you.
-- Jeff J.
More information about the Newlib
mailing list