Re: [sv-bc] 4.10.4 "Enumerated types in numerical expressions" - unclearness

Brad,

>Following up on http://www.eda.org/sv-bc/hm/3372.html , what does the
>LRM mean in 4.10.3 when it says "Enumerated variables are type-checked
>in [...] arguments [...] and relational operators", especially as they
>are also said to be "auto-cast into integral values".  Are there any
>examples of this alleged type checking in the LRM?

I think I understand the "argument" part.  If an input formal argument of
a task or function is an enum, then passing the actual in is an assignment
to an enum, which would be type-checked.  If an output actual argument is
an enum, then passing the formal out is an assignment to an enum, which
would be type-checked.  If an inout formal or actual is an enum, then at
least one of passing in or out is an assignment to an enum, so it needs to
be type-checked.  All this could have been left out, since argument passing
is defined to be assignment, so it was covered already.

There are also ref arguments, but I assume that those already have
strict type-checking rules that will result in enums being type-checked.

I don't understand what it means about relational operators, which are
the greater/less compares.  There is no definition of how to apply those
to enums except by casting to the base type and comparing those.

My best guess is that it actually meant equality operators, and was an
attempt to catch comparing an enum variable to an enum constant of the
wrong enum type.  But that conflicts with the statement about auto-casting
in expressions.  Maybe the casting to the base type is not supposed to
occur for an equality operator, making it an error to test an enum for
equality to a differently typed value.

I am adding the SV-EC to this, since they were the source of the
"strong-typing" on enums.

Steven Sharp
sharp@cadence.com