Structure pointer question

[Eric S. Raymond]

In article <4524 at haddock.isc.com>, Karl Heuer writes:
>In article <361 at teletron.UUCP> andrew at teletron.UUCP (Andrew Scott) writes:
>>Is it alright to #include "foo.h" and not "bar.h" in a source file if the
>>fields of "struct bar" are not used?
>
>There's no rule that forbids having incomplete types in a program.  They
>only need to be completed if the missing information is required.  The
>incomplete type (obtained by including foo.h) and the complete type (obtained
>by also including bar.h) are compatible types.

Would that it were so! Unfortunately this usage (i.e. specification of an
`incomplete' type with a pointer component that references an unspecified type,
in hopes the compiler will just say "oh, this is a pointer" compile in a
pointer-sized slot and not complain) is *not* portable.

In particular, it choked some early System V Release 1 compilers (the same
ones that enforced a def-ref extern model and required full specification of
union members) and upsets some MS-DOS compilers, especially in mixed-model
environments where the size of pointer-to-unknown-thing is unobvious. I know
old Lattices had this problem; I'm not sure if Microsoft C still does or not.

On some of these compilers, the right thing to do is precede your incomplete
declaration with a stub that declares the unknown thing without specifying
members, i.e.

struct unknown;

struct linklist
{
    /* value parts */

    struct unknown *link;
};

I think this will work on any UNIX compiler. But this corner of the portability
problem is really murky and obscure; I've just had to develop ways of avoiding
such constructions (this is moderately painful, because my C style is LISP-
influenced and leans heavily on list and graph-like structures).

-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: {{uunet,rutgers,ihnp4}!cbmvax,rutgers!vu-vlsi,att}!snark!eric
      Post: 22 South Warren Avenue, Malvern, PA 19355   Phone: (215)-296-5718