Subject: Re: kern/2523: audio(4) nits
To: None <jhawk@mit.edu>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: netbsd-bugs
Date: 06/08/1996 13:34:33
>>> 	audio(4) leaves out #include of <sys/types.h>, and [...]
>> Isn't this really a bug in <sys/audioio.h>?
> By such an argument, BTW, almost no one should be including
> sys/types.h...

Right, and I almost never do.  I maintain a shadow include tree that
"fixes" these "bugs" (for such I consider them) in the include files;
for example, on my NeXT, /local/mouse/include/sys/socket.h
(<sys/socket.h> in the shadow tree) reads

	#ifndef _SOCKET_H_34abf9e0_
	#define _SOCKET_H_34abf9e0_
	
	#include <sys/types.h>
	
	#include "/usr/include/sys/socket.h"
	
	#endif

I've been considering taking my shadow tree for NetBSD and packaging it
all up into a jumbo PR....

> It would be a pretty hefty change to go through and modify this lots
> of places,

Not all that big a change.  Anything that worked before would continue
to work, and I can give you a list of many, perhaps even most, of the
include files that suffer from this "require something but not include
it" problem.

> and would lead to lots of programs #including it twice (on the grand
> scheme of things extra inclusion of files protected against multiple
> inclusion just isn't that big a deal, I'll admit, but it does have
> some aesthetic detriment associated with it).

I have no aesthetic problem with <sys/types.h> being hit twice (or
more) during the cpp run; that strikes me as being completely outside
the bounds of aesthetics.  It _does_ seem ugly to me that the source
file should have to include something it has no need for just because
something it _does_ need has need of it.  For example, if some program
wants to use writev, <sys/uio.h> is all it ought to need - it doesn't
use anything from <sys/types.h> itself, so it shouldn't need to include
<sys/types.h>.

It also seems ugly to me that the order in which the include files are
included matters; each include file should be an independent interface,
such that the block of includes can be re-ordered arbitrarily without
affecting functionality...at least where system include files are
concerned ("system" meaning, more or less, anything from /usr/include).
For example, I sort my includes by length of line; to return to the
previous paragraph's example, this would (if I included <sys/types.h>
myself, for example if _my_ code uses some types from it) put
<sys/uio.h> before <sys/types.h>.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu