Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Jul 2000 09:19:10 -0500
From:      "Jim King" <king@sstar.com>
To:        "Thomas David Rivers" <rivers@dignus.com>, <gram@cequrux.com>
Cc:        <freebsd-stable@FreeBSD.ORG>
Subject:   Re: Any chance of changing struct member names in nameser.h?
Message-ID:  <003d01bfe81e$553eb8a0$a44b8486@jking>
References:  <200007071320.JAA86645@lakes.dignus.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Thomas David Rivers wrote:

> > > > Actually, I was wronng - the nameser.h in contrib/bind is fine. But
the
> > > > one in include/arpa/nameser.h is not, so this *is* specific to
> > > > FreeBSD/KAME...
> > >
> > > imho, the right way to handle this is in your source, using an 'extern
"C"'
> > > directive to tell the compiler that it's including a C header and not
a C++
> > > header.  e.g.
> > >
> > > extern "C" {
> > > #include <header_with_cpp_bogons.h>
> > > }
> > >
> > > If the #include directive is in another header file that might be used
in
> > > both C and C++ programs you'd probably want to put some '#ifdef
__cplusplus'
> > > around the extern's.  See section 9.2.4 in Stroustrup 3rd edition for
a good
> > > example.
> >
> > Great idea, except I thought of that long ago and it doesn't work.
> >
> > gram
>
>  Nope - it wouldn't.
>
>  extern "C" doesn't mean
>
> "The following source is C code"
>
>  what it means is that any external linkage generated will use C
>  linkage conventions.   For most C++ implementations, this means
>  "don't mangle function names".
>
>  The source within an `extern "C"' block has to be parsable by
>  the C++ parser... it's still C++.
>
>  For example, you can't say:
>
> extern "PASCAL" {
> ... pascal source ...
> }
>
>  and expect that to work...
>
>
>  That's my understanding of how this works, anyway...

You're right, my bad.  Son of a gun, I've used 'extern "C"' for gobs of
stuff but I guess I never ran into C header files that had C++ reserved
words.

In that case, although it's considerably more work I'd take a look at
writing some C wrappers around the offending stuff.  You could write the
wrappers such that they'd compile with the offending include file, and be
callable from C++.  Sounds tedious and time consuming, but it might be
quicker than waiting for someone to fix the headers in question.

Jim




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003d01bfe81e$553eb8a0$a44b8486>