Re: [sv-bc] Mantis 1067 (out-of-bounds access to arrays)

Gord, thanks for that review. I agree with all your comments and I've
uploaded a modified proposal (v3). I'd be grateful for feedback on the
following two points:

(1) Use of the term "address"
Throughout 11.5 the original LRM text rather consistently uses "address"
to describe an array subscript, while most other parts of the LRM use
"subscript" or "index". It would have been disruptive and possibly
controversial to change that, so instead I've tried to be consistent in
using "address" everywhere within that clause to avoid confusion with
"index" as in "indexed part select". I don't like it, but I think the
intent is clear enough.

(2) Nonexistent array element value for unpacked aggregates
I realized that I'd missed any mention of struct member initializers in
table 7-1, so I've added something for that. However, this raises again
the question I asked in note 10510 in the Mantis item. Reading an
out-of-bounds element whose type is a fixed-size unpacked array, or a
struct, effectively causes a whole new variable to be brought into
existence and it's not obvious to me whether its elements/members should
follow the table 7-1 rules, or the default initial value rules (table
6-7). This matters for events. Consider:

   typedef event EA[3];
   EA ea; // array of events
   EA eaa[2]; // array of arrays of events

   initial begin
     event e = ea[100]; // yields null, as per table 7-1
     EA ee = eaa[100]; // is ee[0] null, or a new event?

I really don't know what is the desired behaviour here; can anyone comment?

Jonathan

On 14/09/2011 03:13, Gordon Vreugdenhil wrote:
> A few minor suggestions below.
>
> First, the second sentence of 7.4.6 is now:
>
> The result of reading from an unpacked array of any kind with
> an invalid index shall return the value specified in Table 7-1.
>
> This has managed to become a very awkward sentence (not due
> to your changes Jonathan). Can we just have:
>
> Reading from an unpacked array of any kind with
> an invalid index shall return the value specified in Table 7-1.
>
> At least we should get rid of "the result ... shall return..."
> structure of the sentence.
>
>
> I think that we now need to be more careful in 7.8.6. It
> has:
> If an invalid index (i.e., 4-state expression....
> But the proposal now very clearly says that "invalid index"
> is *either* out-of-bound or containing x/z. 7.8.6 suggests
> by the parenthetical comment that "invalid" is just the
> x/z case. The parenthetical comment in 7.10.1 is fine as
> it covers both cases now.
>
> Finally, in 11.5.1 and 11.5.2, shouldn't we change:
> If the bit-select is out of bounds ....
> to something like:
> If the bit-select index is invalid (out of bounds ...)
>
> That would keep the use of "invalid" with the parenthetical
> rephrasing consistent.
>
> Gord.
>
> On 9/13/2011 9:47 AM, Jonathan Bromley wrote:
>> hi BC, EC,
>>
>> I have finally found time to pick up the tweaking of Mantis 1067,
>> which has been outstanding for a long while. There's a new proposal
>> ("1067-proposal-v2.pdf") which I hope deals with the many issues
>> raised by Shalom's analysis. I don't know if there is sufficient
>> time or bandwidth to consider it for the current PAR. I think it
>> would be good to get these LRM details cleared up for what is a
>> rather fundamental part of the language, even though everyone seems
>> basically to be agreed about the intent.
>>
>> There was some uncertainty about whether this was a BC or EC issue,
>> hence the mail to both committees.
>>
>> Regards
>> Jonathan Bromley
>>
>

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