RE: [sv-bc] RE: Enum assignment via packed struct

Not to rub more salt into the wound<http://idioms.thefreedictionary.com/rub+salt+into+wounds>, but this is one more side-effect of fixing 'int's at 32-bits. When the sizes of int's and few other data types including basic enums were implementation dependent, variables of those types were not allowed to be a part of a packed array or struct, so this issue did not exist..

Any packed data type is by definition an implicit union with an integral type whose size is the total number of bits in the packed type. It's really too late to prohibit enums from packed structs at this point as tools are far too lenient with the existing restrictions. We can only clarify where the type safety of an enum is lost so that tools can provide the appropriate warning mechanisms.

Dave
Mentor Graphics

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Wednesday, June 20, 2012 11:49 PM
To: Greg Jaxon
Cc: Surya Pratik Saha; sv-bc@eda.org
Subject: RE: [sv-bc] RE: Enum assignment via packed struct

Mantis 1595 is still open on the subject of enums as members of packed structs.

Shalom

From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]<mailto:[mailto:Greg.Jaxon@synopsys.com]>
Sent: Wednesday, June 20, 2012 22:18
To: Bresticker, Shalom
Cc: Surya Pratik Saha; sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: Re: [sv-bc] RE: Enum assignment via packed struct

Shalom is right that there is evidence the loophole was not intentional:
7.2.1 Packed structures
Only packed data types and the integer data types summarized in Table 6-8 (see 6.11) shall be legal in
packed structures.
Table 6-8 does not include enum types.
but it is still left gaping open:
7.4.1 Packed Arrays
Packed arrays can be made of only the single bit data types (bit, logic, reg), enumerated types, and recursively other packed arrays and packed structures.
Recall that explicit casting is also permitted to create non-enumerated values of an enum type.
These openings increase the risks of exploiting any information added by the restriction of possible values.
I would argue that by using these "unsafe" constructs, the user has accepted the risk that a
compiler will use a fact their usage no longer supports, but not everyone agrees on this point.

Greg Jaxon

On 6/20/2012 8:01 AM, Bresticker, Shalom wrote:
Hi,

This was previously noted in http://www.eda-stds.org/sv-bc/hm/5169.html.

However, it is not clear to me that according to a strict reading of the LRM, an enum may be a member of a packed struct.

Regards,
Shalom

From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Surya Pratik Saha
Sent: Wednesday, June 20, 2012 15:50
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] Enum assignment via packed struct

Hi,
As per LRM, an enum variable can only be assigned to another enum variable of same type or enum member. But if it is part of a packed struct, then the restriction can be overridden. Please see the following e.g.:

module top;
    typedef enum bit [1:0] {X, Y, Z} et;
    typedef struct packed {
        et e;
    } st;
    et e;
    st s;
    initial begin
        s = 4; // Passing
        e = 4; // Failing
    end
endmodule

Does LRM say anything about that? Should it not be disallowed by some way?

Regards
Surya

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Received on Thu Jun 21 23:14:14 2012