Path: utzoo!attcan!uunet!husc6!spdcc!ima!haddock!karl From: karl@haddock.ISC.COM (Karl Heuer) Newsgroups: comp.lang.c Subject: Re: Structure pointer question Message-ID: <4606@haddock.ISC.COM> Date: 17 Jun 88 17:15:25 GMT References: <361@teletron.uucp> <8074@brl-smoke.arpa> <4524@haddock.isc.com>Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Organization: Interactive Systems, Boston Lines: 26 In article eric@snark.UUCP (Eric S. Raymond) writes: >In article <4524@haddock.isc.com>, Karl Heuer writes: >>There's no rule that forbids having incomplete types in a program. They >>only need to be completed if the missing information is required. > >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. It's not a pointer to a completely unspecified type. It's a pointer to a struct with unknown contents. (This matters. Although pointer-to-char and pointer-to-int might have different internal representations, pointer-to- -struct-foo and pointer-to-struct-bar cannot%.) >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 { ...; struct unknown *link; }; This contains no more information than without the stub, so I fail to see why the compiler should care. My view is that such a compiler is broken. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint % I believe this can be proved using the dpANS, and probably just from K&R.