🚀 go-pugleaf

 In article <1317@tdat.teradata.COM> swf@tdat.teradata.com (Stanley Friesen) writes:
 >In article <9210260134.AA12733@enet-gw.pa.dec.com> diamond@jit081.enet.dec.com (26-Oct-1992 1033) writes:
 >>For the fourth time, if the suggestion posted by Mr. Spencer and several
 >>other writers (to add a declaration of the struct _opaque tag before the
 >>function) has any validity at all, if their version of opaqueness works,
 >>then Mr. Schilling's original version was equally valid.

 >>Think about it.  Do you believe that this example
 >>  struct _opaque;
 >>  extern fubar(struct _opaque *);
 >>  /* struct _opaque never gets completed in this translation unit */
 >>  struct opaque *x;
 >>  fubar(x);
 >>should work?  If so, why?

 >It should produce an error (possibly only a warning).
 >It should complain about a possible type mismatch between the call and the
 >prototype.

 >Since, given only the code specified, the compiler cannot determine whether
 >struct opaque and struct _opaque are compatible it must be prepared to treat
 >them as incompatible.

 Congratulations.  This typo should indeed yield a diagnostic.
 Now, please try pretending that the typo is fixed, and that the tag is
 named _opaque just as it has been 500 other times during this discussion.
 Now what happens?

 >>Then try finding what makes your type compatible with another translation
 >>unit's complete type.

 >The standard compatibility rule in 3.1.2.6.

 I cannot find anything in 3.1.2.6 that says that an incomplete type in one
 translation unit is compatible with a complete type in another translation
 unit.  Please give the line number.
 --
 Norman Diamond       diamond@jit081.enet.dec.com
 If this were the company's opinion, I wouldn't be allowed to post it.
 "It's been a lovely recession."