Subject: Re: includes pulling in what they need?
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 12/08/1998 11:32:20
>> I'm trying to get some Linux software using network routines to run
>> under NetBSD,
>> and I wonder if it would be possible to our headers that they pull
>> in any additional headers, instead of just breaking because of
>> undefined data types.
> Which headers, specifically, are you thinking of?
I didn't write the original message...BUT, as someone who strongly
believes that headers should never depend on other headers being
included, I've been fixing these problems as I find them.
Here's what I've found, not restricting myself to networking headers.
(Note, this list is hand-typed while flipping through my patch tree, so
it may contain typos, though I've tried to be careful.)
<arpa/inet.h> needs <netinet/in.h>
SPARC <machine/endian.h> needs <machine/types.h>
SPARC <machine/vuid_event.h> needs <sys/time.h> and <sys/types.h>
<net/bpf.h> needs <sys/time.h>
<net/if.h> needs <sys/socket.h>
<net/if_arp.h> needs <sys/socket.h>
<netinet/icmp_var.h> needs <netinet/ip_icmp.h> and <sys/types.h>
<netinet/ip.h> needs <netinet/in.h>
<netinet/ip_icmp.h> needs <netinet/in_systm.h>, <netinet/ip.h>,
<netinet/in.h>, and <sys/types.h>
<netinet/udp_var.h> needs <netinet/ip_var.h> and <netinet/udp.h>
<netns/ns.h> needs <sys/types.h>
<sys/gmon.h> needs <sys/types.h>
<sys/mman.h> needs <sys/types.h>
<sys/proc.h> needs some, but I have enough other patches to
sys/sys/proc.h that I can't be confident I've picked out only
the necessary files. I find I need <sys/types.h>,
<sys/param.h>, <sys/cdefs.h>, and <sys/time.h>.
<sys/resource.h> needs <sys/types.h>
<sys/select.h> needs <sys/types.h>
<sys/socket.h> needs <sys/types.h>
<sys/ucred.h> needs <sys/param.h> and <sys/types.h>
<sys/uio.h> needs <sys/types.h>
<sys/un.h> needs <sys/types.h>
<ufs/ffs/fs.h> needs <sys/param.h> and <ufs/ufs/dinode.h>
> there are standards conformance issues to consider before doing this.
How so? Certainly in many of the above cases, file A, if included
without file B, produces compiler errors; if you can't even compile
when you include A without including B, I have no hesitation making A
include B itself - either the standard with which this putatively
disagrees is sufficiently broken to be ignored, or A is broken for
needing B in the first place (and needs fixing, but in the meantime
it's nice to be able to compile programs).
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B