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

On 9/14/2011 12:34 AM, Jonathan Bromley wrote:
> 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.
>

Ok.

> (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?
>

I view an "event" as being essentially a handle to an event "object"
which has an
implicit construction related to the declaration. I think that view is
supported
by the LRM's discussion of the "event object".

So the question is whether the "default value" of the handle is null with
an implied constructor call (if there is no initializer) or if the
"default value"
is a new event. The existing table says that it is null; I don't see any
reason to view an array of such handles differently. It might be
worthwhile to clarify at some point that event handles have defaults
of null but that an event *declaration* implicitly constructs a new event
object if no assignment initializer is specified. That would make the
description more consistent in situations as the one that you describe.

Gord.

> 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
>>>
>>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.