Path: utzoo!attcan!uunet!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.lang.c Subject: Re: Structure pointer question Summary: Unfortunately, this isn't portable Message-ID:Date: 14 Jun 88 14:55:31 GMT References: <361@teletron.uucp> <8074@brl-smoke.arpa> <4524@haddock.isc.com> Organization: Wild-Eyed Extremists for Freedom, Inc. Lines: 43 In article <4524@haddock.isc.com>, Karl Heuer writes: >In article <361@teletron.UUCP> andrew@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