Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!taumet!steve From: steve@taumet.com (Stephen Clamage) Newsgroups: comp.std.c Subject: Re: Pointers to Incomplete Types in Prototypes Message-ID: <703@taumet.com> Date: 3 May 91 17:02:41 GMT References: <700@taumet.com> Organization: Taumetric Corporation, San Diego Lines: 36 xor@aix01.aix.rpi.edu (Joseph Schwartz) writes: >In article <700@taumet.com> steve@taumet.com (Stephen Clamage) writes: >>As shown, the prototype declares "struct bar" to be an incomplete type >>*local to the prototype*, and hence unavailable outside the prototype. >Your claim that struct bar has local scope to the prototype is pretty >scary. In many of our cases, a function foo is declared with a prototype >in an included header file, and then a struct bar is defined in a second >included header file, and finally the function foo is called from the >.c file that's been doing the #including. As I quoted in another posting, this is explicit in the Standard, in section 3.1.2.1, scary or not. What you cite seems to be currently common in Unix implementations which are converting to ANSI-style prototypes. I have found many headers which are incomplete in this respect, having missing prototypes (which isn't always important for C, but is devastating in C++), and exactly this problem with structs being first declared in prototype scope. The thing to do is to report these to the vendor as bugs, and hope they get fixed in the next release. In the mean time, you can edit the system headers, or supply corrected versions in a local directory which is searched first. >I'm aware that if I said: > extern void foo(struct bar *stool); >then stool would be local to the prototype. I'm skeptical that this >also holds for struct/union tags. There is nothing necessarily wrong with being skeptical, but in this case, the C Standard is explicit as it can be, leaving no room for doubt. -- Steve Clamage, TauMetric Corp, steve@taumet.com