Date: Wed, 8 Jan 1997 23:15:29 +1100 (EST) From: proff@suburbia.net To: dufault@hda.com (Peter Dufault) Cc: hackers@freebsd.org Subject: Re: #include file xref philosophy Message-ID: <19970108121529.5416.qmail@suburbia.net> In-Reply-To: <199701081012.FAA03591@hda.hda.com> from Peter Dufault at "Jan 8, 97 05:12:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > >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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970108121529.5416.qmail>