From owner-freebsd-stable Fri Jul 7 7:19:24 2000 Delivered-To: freebsd-stable@freebsd.org Received: from marble.fbcc.com (ns2.fbcc.com [216.54.252.3]) by hub.freebsd.org (Postfix) with SMTP id 8BDC337B604 for ; Fri, 7 Jul 2000 07:19:19 -0700 (PDT) (envelope-from king@sstar.com) Received: (qmail 13270 invoked from network); 7 Jul 2000 14:21:52 -0000 Received: from unknown (HELO bluto.jimking.net) (216.54.255.8) by ns2.fbcc.com with SMTP; 7 Jul 2000 14:21:52 -0000 Received: from jking (jking.lgc.com [134.132.75.164]) by bluto.jimking.net (8.9.3/8.9.3) with SMTP id JAA74017; Fri, 7 Jul 2000 09:19:11 -0500 (CDT) (envelope-from king@sstar.com) Message-ID: <003d01bfe81e$553eb8a0$a44b8486@jking> From: "Jim King" To: "Thomas David Rivers" , Cc: References: <200007071320.JAA86645@lakes.dignus.com> Subject: Re: Any chance of changing struct member names in nameser.h? Date: Fri, 7 Jul 2000 09:19:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > > } > > > > > > 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