From owner-freebsd-current  Thu Dec 31 12:52:43 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA18137
          for freebsd-current-outgoing; Thu, 31 Dec 1998 12:52:43 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from rover.village.org (rover.village.org [204.144.255.49])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA18132
          for <current@freebsd.org>; Thu, 31 Dec 1998 12:52:39 -0800 (PST)
          (envelope-from imp@village.org)
Received: from harmony [10.0.0.6] 
	by rover.village.org with esmtp (Exim 1.71 #1)
	id 0zvp4m-0000Vr-00; Thu, 31 Dec 1998 13:52:12 -0700
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id NAA01102; Thu, 31 Dec 1998 13:50:08 -0700 (MST)
Message-Id: <199812312050.NAA01102@harmony.village.org>
To: Alex Zepeda <garbanzo@hooked.net>
Subject: Re: egcs chokes on netinet/in.h.. 
Cc: current <current@FreeBSD.ORG>
In-reply-to: Your message of "Thu, 31 Dec 1998 11:42:33 PST."
		<Pine.BSF.4.05.9812311139420.321-100000@zippy.dyn.ml.org> 
References: <Pine.BSF.4.05.9812311139420.321-100000@zippy.dyn.ml.org>  
Date: Thu, 31 Dec 1998 13:50:08 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.05.9812311139420.321-100000@zippy.dyn.ml.org> Alex Zepeda writes:
: > extern "C" {
: > #include <netinet/in.h>
: > }
: 
: I'd rather not "fix" our code, *sigh*.

Does the proposed fix fix the problem?  I'd be surprised if it
actually fixed the problem.  extern "C" doesn't mean treat the
following as having C semantics, just that the following has C linkage
and calling conventions (which are two different things in this case).

About the only thing that I could suggest would be to have a member
that is named differently for C++, like motif and Xt do for a member
named 'class'.

Actually, I could see something like:
struct ip_opts {
	struct	in_addr ip_dst;		/* first hop, 0 w/o src rt */
	char	ipopts[40];		/* actually variable in size */
};

#ifndef __cplusplus
#define ip_opts ipopts
#endif

But that runs into problems when you say struct ip_opts, so that
wouldn't work.  I fear the best solution would be:
struct ip_opts {
	struct	in_addr ip_dst;		/* first hop, 0 w/o src rt */
#ifdef __cplusplus
	char	ipopts[40];		/* actually variable in size */
#else
	char	ip_opts[40];
#endif
};


And then in your code you could say something gross like:

#ifndef __FreeBSD
#define ioopts io_ipts
#endif

But then it will fail in the same way with newer compilers on other
systems.

Warner

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