Date: Wed, 8 Jan 1997 12:36:31 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, proff@iq.org Subject: Re: #include file xref philosophy Message-ID: <199701080136.MAA12519@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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 <sys/types.h> to be included before including any other POSIX header. >things like <dirent.h> needing the code that includes it, include ><sys/types.h> before hand. In particular, before including <dirent.h>. (<dirent.h> used to be self-sufficient in FreeBSD, but a merge from Lite2 made it depend on <sys/types.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701080136.MAA12519>