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.