Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: Problem with prototypes and incomplete types
Message-ID: <9737@smoke.BRL.MIL>
Date: 27 Feb 89 17:47:31 GMT
References: <237@harrier.ukc.ac.uk>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <237@harrier.ukc.ac.uk> mtr@ukc.ac.uk (M.T.Russell) writes:
>Is gcc right to object to incomplete types in function prototypes?

Logically it might be thought to make a difference.  However, we
once deduced from various constraints scattered throughtout the C
language that "all structure pointers have to smell the same", i.e.
have the same representation.  (Strictly speaking, this assumes the
compiler is not applying global code analysis to identify places
where shortcuts can be applied, so there should be an "as if" in
there somewhere.)  Therefore, the compiler should easily be able to
cope with not knowing the precise structure type in your example.
An incomplete array is similarly no problem.  An incomplete struct
or union parameter (as opposed to a pointer to one) could be more
bothersome, but not noticeably worse than for incomplete data types.

I don't think the pANS disallows an incomplete type in this context.
Certainly the problem is not that the struct tag "object" had
prototype scope, because the scope of the tag had already begun.

>One workaround is to declare destroy as
>	void (*destroy)(void *);

Better in this particular example might be
	void (*destroy)();
so that SOME type checking could still be performed.

I don't recall any public review comments on this, but it's a good
point.  I hope I've interpreted this correctly..