RE: [sv-bc] Assignment compatibility of packed arrays of enums

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Sat Oct 03 2009 - 23:24:44 PDT
And the LRM explicitly discusses how an out-of-range value can be assigned.
For example, in 6.19.3: "Casting can be used to perform an assignment of a different data type, or an out-of-range value, to an enumerated type."

Yet another way is if there are multiple drivers of different values to an enum net (contention).

Shalom

________________________________
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of jonathan.bromley@doulos.com
Sent: Sunday, October 04, 2009 3:07 AM
To: Greg Jaxon; sv-bc@eda.org
Subject: Re: [sv-bc] Assignment compatibility of packed arrays of enums


> The question ... is what the LRM requires when an
> enum element or field that's been abused by type-unsafe
> assignment is fetched as an enum value.
> Is a compiler justified in thinking this value is confined
> to the enumerated set of values?

Surely not.  The value is still there in the underlying
representation.  It will compare as unequal with any of
the enum literals.  It can be auto-cast to an integral
value by appropriate (ab)use of the enum variable. And
if one of the enum methods such as .next() is applied
to it, the LRM mandates the result to be the default
initial value for the underlying type.  All this is
clear enough, though perhaps a little stressful for
milquetoasts such as me who were brought up on VHDL
enumerated types.
---------------------------------------------------------------------
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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat Oct 3 23:27:00 2009

This archive was generated by hypermail 2.1.8 : Sat Oct 03 2009 - 23:28:05 PDT