From owner-freebsd-hackers Tue Jan 7 17:42:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA03471 for hackers-outgoing; Tue, 7 Jan 1997 17:42:41 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA03433 for ; Tue, 7 Jan 1997 17:42:29 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id MAA12519; Wed, 8 Jan 1997 12:36:31 +1100 Date: Wed, 8 Jan 1997 12:36:31 +1100 From: Bruce Evans Message-Id: <199701080136.MAA12519@godzilla.zeta.org.au> To: hackers@freebsd.org, proff@iq.org Subject: Re: #include file xref philosophy Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What is the -current philosophy on intra #include file dependencies? My philosophy is: - all headers should be self-sufficient - this should be implemented without including any standard headers - this shall be implemented without any namespace pollution - applications shouldn't assume any more than standards specify >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 to be included before including any other POSIX header. >things like needing the code that includes it, include > before hand. In particular, before including . ( used to be self-sufficient in FreeBSD, but a merge from Lite2 made it depend on for u_int_*_t. >Appart from portability issues, which I am increasingly encountering, >I find the idea that user developed .c code must magically "know" >what each /usr/include/* file needs and in what order very ugly >and ecapsulation breaking. The ordering problems are mainly caused by some headers being more self-sufficent than others, with this being implemented in a bad way by including other headers. You can then satisfy magic unknown prerequisites by including an even more more magic list of other headers. Bruce