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.