Subject: Re: [sv-bc] question about type assignment compatibility
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Wed Nov 19 2003 - 14:34:55 PST
I'm also having problems with the sentence (7.14 or 7.15):
> Unpacked structure types are equivalent by the hierarchical name of their type alone.
I agree with the intent to use something stronger than structural isomorphism
for "equivalence". But reading literally, the declaration struct {...} a,b;
produces two variables of an anonymous type (it has no hierarchical name). Yet we
expect a and b to be compatible for assignment, where struct {...} c; struct {...} d;
are not compatible.
I'd rather say:
Each occurrence of the "struct{...}" construct without a "packed" modifier
defines an unpacked structure type not equivalent to any other unpacked or
packed structure type. Because multiple definitions of the same name are
prohibited, two type references to the same hierarchical name are perforce equivalent.
Equivalent types may acquire different names through typedef or type parameter
definitions. For type references made in separate elaboration steps, equivalence
of hierarchical type name shall be sufficient evidence of equivalence.
I'm not sure if "const" qualifiers are considered to be properties of types
or of variables, but if they can be used in typedefs, then it should be clear
that different const-ness does not mean inequivalent type.
Greg Jaxon
Francoise Martinolle wrote:
> With the wording in section 7.15 (issue 14), I interpret that the
> following 2 structs assignment are still illegal.
>
> Is that right? I think it should be legal. The wording should be refined
> to indicate that aliases of typedef are considered identical types.
>
> typedef struct { int b; } st1;
> typedef st1 st2;
>
> st1 sv1;
> st2 sv2;
>
> initial
> sv1 = sv2;
This archive was generated by hypermail 2b28 : Wed Nov 19 2003 - 14:37:34 PST