jsa@edg1.UUCP (J. Stephen Adamczyk) (12/06/88)
Is the following legal, according to the May 13 (88-001) draft?
struct {int a;} v1;
struct {int a;} v2 = {1};
void f() {
v1 = v2; /* <--- Are the structs compatible? */
}
For the assignment to be legal, the two struct types have to be
compatible. To be compatible, they have to be "the same" (3.1.2.6).
According to 3.5.2.1 (semantics), "The presence of a struct-declaration-list
in a struct-or-union-specifier declares a new type, within a translation
unit." Since I can't find any other section that says that the two
structs above are the same, I conclude that the two struct types are
incompatible, and therefore the assignment is not allowed.
I know that 3.1.2.6 says that "two structure, union, or enumeration
types declared in separate translation units are compatible if they have
the same number of members, the same member names, and compatible member
types". However, this says nothing about types within one translation
unit.
Any thoughts?
Steve Adamczykhenry@utzoo.uucp (Henry Spencer) (12/07/88)
In article <288@edg1.UUCP> jsa@edg1.UUCP (J. Stephen Adamczyk) writes: >Is the following legal, according to the May 13 (88-001) draft? > >struct {int a;} v1; >struct {int a;} v2 = {1}; ... > v1 = v2; /* <--- Are the structs compatible? */ No. The two structs are different types. >I know that 3.1.2.6 says that "two structure, union, or enumeration >types declared in separate translation units are compatible if they have >the same number of members, the same member names, and compatible member >types". However, this says nothing about types within one translation >unit. This rule is necessary because otherwise there is no way that structs etc. declared in different translation units could ever be compatible. There is no such thing as having "the same declaration" appear in two different translation units -- by definition, it's two different declarations that happen to be textually identical. This is basically a concession to the usual C compilation environment, in which the compiler does not save state from one translation unit to be used in compiling another. Within a single translation unit, this concession is not necessary and is not made. It would arguably be cleaner to have the "same declaration" rule apply throughout in theory, but with an implementation-defined possibility of relaxing the rule in the event that the implementation can't do that. That way, an implementation that did save state across compilations could enforce the stricter rule. Doing the details right could be really tricky, though, and in any case it's too late. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu