RE: [sv-bc] E-mail Vote: Closes 12am PST Nov 17

Mark,

I would like to make some comments on this vote against #291.

The elements of #291's proposal that you disagree with have already
been passed by the committee in SV-BC #111. The SV-BC has not
backtracked on that proposal since the vote was registered.
If you can find a contradictory proposal that was passed subce
that time, that would be valuable for everyone to know about(!)

#291's unique contribution is to nail down a precise definition for the
term "corresponding array elements". The text of #291 simply gathers
up
#111's approved changes and merges them together with new changes made
in the same sections. So we are not actually voting on #111 again.
Rather, we are voting on a precisely defining the meaning of
"corresponding array elements".

Recall, the intention of #111 is to make sure that implicit casts and
explicit casts (not just bitstream casts) always yield the same results
under all legal use circumstances.

You seem to have raised some interesting points regarding bitstream
casting which I think would be of benefit to discuss. These could
possibly
become the source of a separate erratum. But I would appreciate it if
we
could pass #291 based on its value for clarifying assignment order, and
then deal with bitstream casting separately.

Thanks!
Doug

> 291 ___Yes _x_No
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000291
> I have no problem with the clarification of the assignment order,
> but on the change from assignment compatible elements to type
> equivalent
> elements, I am concerned that we have completely changed
> direction on the
> issues of array assignment and casting several times over the last
> year. The argument is we need to make these changes to be consistent
> with bit stream casting, but I am not convinced that the current
> description of bit stream casting makes sense, particularly
> concerning dynamic types. Consider this case:
>
> typedef struct ( byte a[]; } ST;
> typedef ST TypeA[0:1];
> TypeA a;
> TypeA b;
>
> I think
>
> a = b;
>
> and
> a = TypeA'(b);
>
> do completely different things both with and without this change.
>
Received on Tue Nov 16 19:27:18 2004