t-itoh@utsm.nm.fujitsu.co.jp (Tsutomu Itoh) (02/07/91)
Could someone please clarify the correct implementation of structure
tags and incomplete types as in the following fragments, assume there
are no other declarations of struct foo in scope:-
1a.
struct foo {int i;};
struct foo;
struct foo bar;
1b.
struct foo;
struct foo {int i;};
struct foo bar;
Should the compiler object to 1a but not to 1b as implied in 3.5.2.3?
If so it seems many compilers allow both.
2a
int bar(struct foo);
struct foo {int i;};
2b
struct foo;
int bar(struct foo);
struct foo {int i;};
Is the empty structure declaration necessary?
If you mail any replies please cc to paul@tetrauk.uucp
Thanks
--
Paul Ashton
--
$BIY;NDL3t<02q<R!!>BDE9)>l!!%*!<%W%s%7%93+!KBh0l3+H/ItBhFs3+H/2](J
$B0KF#!!6P!!!!(Jt-itoh@nm.fujitsu.co.jp steve@taumet.com (Stephen Clamage) (02/09/91)
t-itoh@utsm.nm.fujitsu.co.jp (Tsutomu Itoh) writes: >1a. >struct foo {int i;}; >struct foo; >struct foo bar; >1b. >struct foo; >struct foo {int i;}; >struct foo bar; Both of these are ok. In 1a there is no incomplete declaration. In 1b, line 1 is an incomplete declaration, completed in line 2, which is before the complete declaration is needed. >2a >int bar(struct foo); >struct foo {int i;}; This will not do what you want. The scope of struct foo is the prototype of function bar. Any struct foo declared later, as in line 2, is a different type from that in the prototype. There is no way to pass an argument to function bar, since no possible variable will be of a type compatible with the struct foo in the prototype. Not all compilers get this right. The prototype for bar is illegal in C++, by the way, for exactly this reason. >2b >struct foo; >int bar(struct foo); >struct foo {int i;}; >Is the empty structure declaration necessary? Some declaration is necessary for the reasons given above. With a declaration (complete or incomplete) for struct foo in scope when the prototype for bar occurs, it is seen that bar takes an argument of that same type struct foo. In this case, the declaration of foo is completed in line 3. -- Steve Clamage, TauMetric Corp, steve@taumet.com
gwyn@smoke.brl.mil (Doug Gwyn) (02/09/91)
In article <595@taumet.com> steve@taumet.com (Stephen Clamage) writes: -t-itoh@utsm.nm.fujitsu.co.jp (Tsutomu Itoh) writes: ->1a. ->struct foo {int i;}; ->struct foo; ->struct foo bar; -Both of these are ok. In 1a there is no incomplete declaration. Sure there is; the second "struct foo" type is not completed. If any essential use is made of "bar", there is an error. The second declaration (tag only) in effect cancels the previous "struct foo" type information for the following code. This is a special wart spelled out in 3.5.2.3.
mkahl@world.std.com (Michael Kahl) (02/10/91)
In article <15135@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <595@taumet.com> steve@taumet.com (Stephen Clamage) writes: >-t-itoh@utsm.nm.fujitsu.co.jp (Tsutomu Itoh) writes: >->1a. >->struct foo {int i;}; >->struct foo; >->struct foo bar; >-Both of these are ok. In 1a there is no incomplete declaration. > >Sure there is; the second "struct foo" type is not completed. >If any essential use is made of "bar", there is an error. >The second declaration (tag only) in effect cancels the previous >"struct foo" type information for the following code. This is a >special wart spelled out in 3.5.2.3. Are you certain? 3.5.2.3 says a tag-only struct declaration "specifies a new type distinct from any type with the same tag IN AN ENCLOSING SCOPE (if any)." (My emphasis.) From the Rationale it is clear that the purpose of this feature is to allow a forward reference in an *inner* block to a struct which already exists in an *outer* block but which will be redeclared in the inner block. I don't see anything in the Standard to suggest that a tag-only declaration "cancels" a previous declaration in the *same* scope. -- Michael Kahl, Symantec Corporation mkahl@world.std.com -or- 75236.3146@compuserve.com Disclaimer: Keep this quiet; what my employer doesn't know won't get me fired.
gwyn@smoke.brl.mil (Doug Gwyn) (02/10/91)
In article <1991Feb9.164052.9691@world.std.com> mkahl@world.std.com (Michael Kahl) writes: >Are you certain? Yes. If you don't believe me, and can't read the very clear specification of this feature in the C standard, you could ask ANSI/X3J11 for a formal interpretation ruling.
mkahl@world.std.com (Michael Kahl) (02/11/91)
In article <15147@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Feb9.164052.9691@world.std.com> mkahl@world.std.com (Michael Kahl) writes: >>Are you certain? > >Yes. If you don't believe me, and can't read the very clear specification >of this feature in the C standard, you could ask ANSI/X3J11 for a formal >interpretation ruling. I have to say I find this reply somewhat ad hominem, not to say rude. I can, in fact, read very clear specifications. In this instance, however, we apparently disagree as to what is specified, and by implication, as to its clarity. I am also willing to countenance the possibility that I may have missed, or misinterpreted, something. Are you? In my original post I presented an argument against your interpretation, specifically referring to the clause "in an enclosing scope" qualifying the statement in the Standard on which you seemed to be basing your position. I also referred to the explanation of this feature given in the Rationale. To reiterate, I see nothing in the Standard or Rationale to suggest that a tag-only struct declaration should "cancel" an existing type declared earlier in the *same* scope. In an enclosing scope, yes, that is the whole point, after all. But since both the Standard and the Rationale are careful to say "in an enclosing scope", I don't believe it applies in the same scope. If you would care to respond to the point, I would be pleased to be educated. However, if you cannot refrain from insulting my intelligence, please don't bother to reply. -- Michael Kahl, Symantec Corporation mkahl@world.std.com -or- 75236.3146@compuserve.com Disclaimer: Keep this quiet; what my employer doesn't know won't get me fired.
gwyn@smoke.brl.mil (Doug Gwyn) (02/11/91)
In article <1991Feb10.185918.10775@world.std.com> mkahl@world.std.com (Michael Kahl) writes: >However, if you cannot refrain from insulting my intelligence, please don't >bother to reply. I don't recall "insulting your intelligence". However, now that you have given me the opportunity I must say I don't see how you could misread the standard the way you have. 3.1.2.1 makes it clear what the precise scope of structure tags is, and any decent dictionary would explain what "enclosing" means. The particular wart that I alluded to previously in 3.5.2.1 that was carefully planted into the standard specifically to achieve this "clear the tag from the name space" function was completely omitted from the initial discussion, which tried to "reason out" what the standard requires from other wording in the standard that was simply not germane to the issue. I was involved in X3J11 discussions of precisely this issue, and am sure that I understand what the committe meant in this regard (which happens to also be what the standard specifies, quite clearly in my opinion). As I said, if you don't believe me and want a formal interpretation, you should request one through the proper channels.
mkahl@world.std.com (Michael Kahl) (02/12/91)
Thank you for that more detailed response. As I now see it, our disagreement stemmed from my interpretation of the term "enclosing scope". I took that to mean "a scope at a higher level", e.g. global scope vs. local scope. It seems that you (and the Standard) are using it simply to mean "a scope whose extent includes the entire (enclosed) scope". I grant that this is a reasonable, if surprising (to me), use of the term, and it does make the Standard read as you say. >I don't recall "insulting your intelligence". Perhaps, not knowing you, I misread you. However, I'm sure you can imagine how I might have perceived a reply which failed to address the point I was making, instead suggesting I might lack the ability to read a clear spec, as representing an insult to my intelligence. I'm pleased to hear you did not mean it the way it came out. >I must say I don't see how you could misread the standard the way you have. I hope that now you can. I assumed "enclosing scope" meant "higher-level" scope. I don't think this was unreasonable, although I see you meant it more literally. I appreciate the clarification. -- Michael Kahl, Symantec Corporation mkahl@world.std.com -or- 75236.3146@compuserve.com Disclaimer: Keep this quiet; what my employer doesn't know won't get me fired.
gwyn@smoke.brl.mil (Doug Gwyn) (02/14/91)
In article <1991Feb12.024839.3487@world.std.com> mkahl@world.std.com (Michael Kahl) writes: >>I must say I don't see how you could misread the standard the way you have. >I hope that now you can. I assumed "enclosing scope" meant "higher-level" >scope. I don't think this was unreasonable, although I see you meant it more >literally. I appreciate the clarification. Actually, from further off-line conversation with Dennis Ritchie, I gather that he favors your reading over mine. This should be additional evidence, if it were needed, that what I thought was a clear specification is more ambiguous than I had judged it to be. The core of the problem seems to be the definition of "same scope" that was added to the standard during public review. The reason for that was that the phrase is used elsewhere in the standard, but since file scope of various identifiers do not have identical range, there was confusion in the opposite direction. From the advantage of hindsight, it probably would have been better to change usage of "same scope" through the standard to something like "coterminating scope" (ugh, well you get the idea), and not have tried to define "same scope" to have a nonintuitive meaning. As I have been suggesting, it would be useful for somebody to request a formal interpretation ruling on this "struct foo;" issue. While I've explained why I believe the intention to be, there is always the possibility that I misunderstood it all along or that the committee would NOW decide to real the standard in a different "literal" way than the original intention. We had to do that to some degree for a couple of other interpretation issues.