Subject: Re: includes question
To: None <tech-kern@NetBSD.ORG>
From: Luke Mewburn <lukem@netbsd.org>
List: tech-kern
Date: 11/12/2002 12:10:06
On Sat, Nov 09, 2002 at 08:38:50PM -0500, Greg A. Woods wrote:
| [ On Saturday, November 9, 2002 at 23:21:42 (+0100), der Mouse wrote: ]
| > Subject: Re: includes question
| >
| > If I use foo_t in my code, I should include the header <bar.h> that
| > defines it, yes. But if I happen to use bleeble(), whose interface
| > does not require me to know foo_t even exists, but bleeble() is
| > declared in the same include file <fribble.h> as another call gringle()
| > whose interface _does_ require its caller to know about foo_t, *then*
| > should I have to include <bar.h>? I maintain I should not. Yet in far
| > too many cases, <fribble.h> produces syntax errors if foo_t is not
| > already defined.
|
| Surely you know you live in a house of cards and that if you don't
| include the right cards at the foundation then they'll all come a
| tumbling down.
|
| If the interface definition declares that thou must #include <bar.h>
| before you #include <fribble.h> then that's the way it must be.
On the other hand, if the interface definition says you must include
<sys/socket.h> and makes *no mention* of <sys/types.h>, then you
shouldn't be required to pull in <sys/types.h> first.
This is a situation that occurs right now with bind(2) (et al); code
written on other systems to the manual pages (including the NetBSD
manual pages!) and to the POSIX standards which only include
<sys/socket.h> will not compile on NetBSD unless <sys/types.h> is
pulled in first.
This is wrong, and our header files should be fixed to match the
standards and our manual pages.
| The only thing I really want to warn about is that the various standards
| we like to admire and adhere to have sometimes got things to say about
| what must be included by whom and where and in what order, it it would
| not really help with compatability and portability to ignore those rules
| and make things work despite them.
Yes; see above.
Luke.