Re: [sv-bc] 6.9.2 Equivalent types - question

Shalom,

    What you say is true, and the edits you propose would not be
incorrect.  In particular, 6.9.2(2) and its example are logically
redundant.

   I'm of the opinion that the parallel construction of these
two sections /does/ serve to highlight a subtle difference
which makes 6.9.1(3) stronger than 6.9.2(2).  But if this
redundancy seems confusing I can support eliminating 6.9.2(2).

   I oppose changing the example given for 6.9.1(3) because:
A) it covers the point where that clause strengthens 6.9.2(2), and
B) it amplifies the last sentence in the intro to section 6.9.

   I could support /adding/ an unpacked example (reuse the
one being deleted, but use new identifiers); that would be fine.
If this was done in 6.9.1 as follows:

> 3) An anonymous enum, struct, or union type matches itself among data objects declared within the same
>    declaration statement and no other data types.

> struct packed {int A; int B;} PAB1, PAB2; // PAB1, PAB2 have matching types
> struct packed {int A; int B;} PAB3;       // the type of PAB3 does not match
>                                           // the type of PAB1
> struct {int A; int B;} UAB1, UAB2;        // UAB1, UAB2 have matching types
> struct {int A; int B;} UAB3;              // the type of UAB3 does not match
>                                           // the type of UAB1 or PAB3

... then in section 6.9.3 (which would renumber as 6.9.2), we
could extend the NOTE there to say:

> In the example of 6.9.1(3), PAB1, PAB2, and PAB3 have equivalent types,
> whereas UAB3 is not type equivalent to UAB1

------------------------------

While rereading this area, I notice that 6.9.1(8) is not quite
right... the claim it makes about enums, structs, unions, and classes
declared in packages is true regardless of whether they have been
given a typedef name.  For instance an anonymous type nested inside
a named type matches everywhere the parent type is imported despite
itself being unnamed.

Please delete the character string " typdef for a" there.

Greg Jaxon


Bresticker, Shalom wrote:
> OK, let me clarify my comments.
> 
> The structure of each sub-section of 6.9 is to say that each level of
> compatibility includes everything included in the preceding level, plus
> a list of additional cases.
> 
> In particular, 6.9.2 (1) says, "If two types match, they are
> equivalent.".
> 
> This IMPLIES, or at least, gives the impression, that 6.9.2 (2)
> describes a case not included in (1), i.e., NON-matching.
> 
> This implication/impression is strengthened by the fact that the example
> in 6.9.1 (3) is of PACKED structs, whereas the text of 6.9.2 (2) and its
> example are of UNPACKED structs.
> 
> The combination of these facts gives a strong impression that 6.9.1(3)
> was intended to relate only to packed structs and unions.
> 
> Since both Francoise and Greg seem to agree that 6.9.1(3) does indeed
> apply to unpacked as well as packed structs and unions,
> 6.9.2(2) should be deleted and the example of 6.9.1(3) should be of
> unpacked structs.
> 
> Thanks,
> Shalom 
> 
> 
>>-----Original Message-----
>>From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
>>Sent: Monday, November 21, 2005 8:27 PM
>>To: Bresticker, Shalom
>>Cc: sv-bc@eda.org
>>Subject: Re: [sv-bc] 6.9.2 Equivalent types - question
>>
>>The relationship between Matching and Equivalence here could
>>be made clearer by changing 6.9.2(2) to say
>>
>>"2) Anonymous enum, unpacked struct, or unpacked union types
>>    are Equivalent if and only if they are Matching."
>>
>>Shalom is right that for these cases, Equivalence is /not/
>>weaker
>>than Matching.  These are the types for which our goal was to
>>provide "strong type checking", so for these, equivalence makes
>>no compromises and becomes as strong as exact matching.
>>
>>Greg Jaxon
>>Synopsys DCSV
>>
>>Bresticker, Shalom wrote:
>>
>>>Hi,
>>>
>>>I have a question on Matching types vs. Equivalent types.
>>>
>>>6.9.1(3) says,
>>>
>>>"3) An anonymous enum, struct, or union type matches itself
>>
>>among data objects declared within the same declaration
>>statement and no other data types.
>>
>>>struct packed {int A; int B;} AB1, AB2;// AB1, AB2 have
>>
>>matching types
>>
>>>struct packed {int A; int B;} AB3;     // the type of AB3
>>
>>does not match the type of AB1"
>>
>>>
>>>6.9.2(2) says,
>>>
>>>"2) An anonymous enum, unpacked struct, or unpacked union
>>
>>type is equivalent to itself among data objects declared within
>>the same declaration statement and no other data types.
>>
>>>struct {int A; int B;} AB1, AB2; // AB1, AB2 have equivalent
>>
>>types
>>
>>>struct {int A; int B;} AB3;      // AB3 is not type
>>
>>equivalent to AB1"
>>
>>>
>>>If we look at the two texts, it seems that the case described
>>
>>by 6.9.2(2) is included in 6.9.1(3). 6.9.2(2) relates only to
>>unpacked structs and unions (ignoring enums for now), whereas
>>6.9.1(3) makes no distinction between unpacked and packed
>>structs and unions.
>>
>>>The example of 6.9.1(3) is of packed structs, but the text
>>
>>makes no such restriction.
>>
>>>Since matching is stronger than equivalence, this seems
>>
>>strange.
>>
>>>Comments?
>>>
>>>Thanks,
>>>Shalom
>>>
>>>
>>>Shalom Bresticker
>>>Intel Jerusalem LAD DA
>>>+972 2 589-6852
>>>+972 54 721-1033
>>>I don't represent Intel
>>>
>>>
> 
>