Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: declarations in include files:  how do YOU feel?
Keywords: declarations include
Message-ID: <10251@smoke.BRL.MIL>
Date: 11 May 89 21:34:20 GMT
References: <179@larry.sal.wisc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <179@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes:
>The situation is, suppose I have a bunch of routines that are packaged
>into a lib.a, and there is an associated include file "lib.h" that
>users need to include.  Should the lib.h file contain extern declarations
>for everything in lib.a, or not?

If the library is naturally divisible into smaller packages (e.g. array
operations, error reporting, ...) then provide a separate header for
each "package" that defines/declares things for just that package.
Otherwise, define/declare them all in lib.h.  If functions in lib.a
can call other functions in lib.a, the user has to be aware of the
total set of external names defined by the library anyway so that he
doesn't accidentally usurp one for his application.  (That would break
functions that called that usurped function.)

Just because a header includes a declaration of a function does not mean
that the function will be linked into the executable image; only if it
(or some other external defined in the same object module) is referred
to will the corresponding object module be linked in.  (There are some
linkers that violate this model, but it's pretty near universally agreed
that they're broken.)