[sv-bc] RE: [sv-ec] Default initial values

Jonathan,

Mantis 2900 addresses your last issue and has a proposal ready to go.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number:   510-354-7439
 

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Jonathan Bromley
> Sent: Sunday, November 07, 2010 10:55 AM
> To: Bresticker, Shalom; sv-ec@eda.org; sv-bc@eda.org
> Subject: [sv-ec] Default initial values
>
> hi BC/EC,
>
> I've been trying to respond to Shalom's feedback on Mantis
> 2794 relating to default initial values and nonexistent
> array entries, and frankly the current LRM situation is a
> mess. I suspect that the intent is fairly clear, and
> well-known to implementers; but getting the LRM to be
> lucid about it will take some cleanup.
>
> 7.4.6 says:
> The result of reading from an array
> with an invalid index shall return
> the default uninitialized value for
> the array element type.
> Apart from the awkward idea that a "result...shall return"
> anything, this doesn't deal correctly with reading an element
> of event type (thanks to Shalom for pointing this out): the
> default for an event is a new event object, but clearly you
> want "null" when you read a missing array element. The
> default uninitialized values are clear and complete in
> Table 6-7, but of course include "new event" for event #
> types - which is wrong for invalid array elements.
>
> For associative arrays, Table 7-1 defines the situation
> and clarifies that reading a nonexistent element of event
> type should yield null. Why is this specific to associative
> arrays? Surely it's just as relevant to any array when
> reading an out-of-bounds or invalid element. The only
> special behavior of associative arrays in this case is
> that they do not evince a warning when a nonexistent
> element is read.
>
> Furthermore, the text associated with Table 7-1
> (in clause 7.8.6) talks about "the default initial value
> for the array type", which is clearly wrong for events
> and seems to contradict Table 7-1. The description of
> out-of-bounds queue access in 7.10.1 makes the same error.
>
> Finally, table 7-1 fails to cover chandle and real types.
>
> It seems to me it would make more sense to delete
> table 7-1 altogether, and to appeal to table 6-7 in
> all these cases but make a special exception for events.
>
> There's yet another issue: If an array has elements of
> some aggregate type, and you try to read an invalid
> element, presumably all leaf elements of the aggregate
> must be populated with default values just as they
> would be for an array element, including "null" for
> any event element. For example:
>
> typedef struct {int i; event e[2]} int_2ev;
> int_2ev i2e[int];
>
> // A new variable of type int_2ev gets new events???
> int_2ev s; // = '{i:0, e:'{new_event, new_event}}
>
> // But reading from an invalid array gives nulls???
> s = i2e[0]; // doesn't exist -
> // now we have s == '{i:0, e:'{null,null}} ????
>
> Is this described unambiguously anywhere in the LRM?
>
> I can't sensibly fix the 2794 proposal until this is
> sorted out. I'm willing to raise a new Mantis and
> write a proposal immediately, but it may be that it's
> already in hand somewhere else?
>
> Thanks
> --
> Jonathan Bromley
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.