Re: [dev-serveez] libserveez.h #includes

[Thien-Thi Nguyen]

() Julian Graham <address@hidden>
() Tue, 13 Nov 2012 00:31:08 -0500

   > Stuff like #include <stdio.h> were never in libserveez.h, so for
   > now i'm inclined to leave them out, due to inertia and lack of
   > gumption mostly.

   Well, actually, it was -- transitively.

   [header reorg]

   that's why building against libserveez.h used to work for me?

Yes, sounds about right.  The overall thrust was (and still is, although
i am wavering on this -- see below) to keep system headers unmentioned
in libserveez.h.

   > Some things are straightforward (AFAICT), like #include <stdio.h>.

   Really? My .c file that was using libserveez.h didn't need anything
   from stdio.h -- and still doesn't, since it's not using any of those
   functions that takes a FILE pointer -- so I had to dig around in
   libserveez.h to see why things were broken. This seems like a bit of
   a violation of encapsulation to me.

True.  I mean straightforward in the sense that the surrounding preproc
conditionals are simple (or even unnecessary) and unlikely to have
different meaning from one system to the next.  That is, as libserveez.h
provider, i might have no qualms adding the naked:

 #include <stdio.h>

or, to be super strict:

 #ifdef HAVE_STDIO_H
 #include <stdio.h>
 #endif

In the first case, clients need do nothing; in the second, they need to
include a configure.ac check for stdio.h, and that check is probably
"standard" enough that there is no operational difference between what
Serveez's configure.ac determines and what theirs determines.

   I saw some commit comments to the effect that header files should
   never #Include <stdio.h>. Is that a general bit of C convention with
   which I'm unfamiliar?

I don't think so.  It's just the lazy programmer trying to shirk
responsibility...

   I'm actually curious, and a Google search reveals a fair number of
   differing opinions on how to organize header file dependencies. My
   M.O. to date has been: If a .c or .h file itself refers to a type or
   function that it does not itself define, then it should #include the
   header that's "responsible" for defining that type, even if that
   header is already transitively #Included.

Yeah, that's the Right Way, or at least a good part of it.  The rest
(what i'm slowly coming to accept) is that w/ libserveez.h, there should
also be libserveez.m4, to guarantee that configure.ac header checks sync
w/ the preproc conditionals, and moreover that the checks are consistent
between libserveez (itself) and client code.

   > [shirking through documentation]

   I suppose if it were documented I could live with it. It still forces
   me to #include libserveez.h with a particular ordering relative to
   stdio.h (i.e., stdio.h and friends must come before libserveez.h),
   which is a little annoying.

Yes.  That won't do.  Looks like it's time to redo serveez.m4 to DTRT.
Probably to be dropped entirely, and a libserveez.m4 (as above) written.

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

pgpfvhjPqPaj9.pgp
Description: PGP signature