From owner-freebsd-hackers  Wed Jan  8 04:16:14 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA01222
          for hackers-outgoing; Wed, 8 Jan 1997 04:16:14 -0800 (PST)
Received: from pdx1.world.net (pdx1.world.net [192.243.32.18])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA01217
          for <hackers@freebsd.org>; Wed, 8 Jan 1997 04:16:11 -0800 (PST)
From: proff@suburbia.net
Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id EAA21905 for <hackers@freebsd.org>; Wed, 8 Jan 1997 04:16:54 -0800 (PST)
Received: (qmail 5418 invoked by uid 110); 8 Jan 1997 12:15:29 -0000
Message-ID: <19970108121529.5416.qmail@suburbia.net>
Subject: Re: #include file xref philosophy
In-Reply-To: <199701081012.FAA03591@hda.hda.com> from Peter Dufault at "Jan 8, 97 05:12:30 am"
To: dufault@hda.com (Peter Dufault)
Date: Wed, 8 Jan 1997 23:15:29 +1100 (EST)
Cc: hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > >Is there any reason for not following the posix line and having
> > >include files resolve all their own dependencies? I'm talking about
> > 
> > That's not the ANSI C line.  POSIX.1 requires <sys/types.h> to be
> > included before including any other POSIX header.
> 
> How about "POSIX.1 sometimes requires that <sys/types.h>
> be included before including some POSIX headers".  They sprinkle
> size_t all over the place so that old programs don't break.
> 

Frankly it is painful. Include files should not break their encapsulation.
include/netinet/*.h are frightful. As a bunch of other things when
-DKERNEL is on. Next time you are writing/modifying an include file, please
keep this in mind. Not having an include file resolve its own dependencies
saves you nothing, but an open(), during CPP. I don't care if possix
says its sometimes ok. Posix is wrong. I just had to manually edit
and recompile 100 .c files in the last two ports I did - ports that
compiled without problem on 6 other platforms, because of #include
stupidity. Someone replied to me 'the magic is in the man page' - well
when the magic is in everyone elses man page and CPP understands how
to parse nroff and -ms macros I'll believe you. This says is to say
nothing of future compatibility issues. What if <foo.h> no longer
needs <bar.h>. Do we restrospectively change the worlds manpages?

Cheers,
Julian <proff@iq.org>