Re: [sv-ec] 10.5.3 The foreach loop

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Tue Jan 22 2008 - 16:48:19 PST
The SV-EC unanimously approved Mantis item 2003 in the
conference call this morning. Mantis item 1447, which
has already been approved, introduced an inconsistency
within the LRM due to the incomplete fix contained in 1447.

Approving Mantis item 2003 makes the change in 1447 complete
and eliminates the inconsistency that 1447 created.
Thank you for bringing this to our attention.


Neil



Bresticker, Shalom wrote:
> Whatever happened to Mantis 1740/2003?
> 
> Shalom 
> 
>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org 
>> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Steven Sharp
>> Sent: Friday, January 18, 2008 11:00 PM
>> To: sv-ec@server.eda.org; danielm@aldec.com.pl
>> Subject: Re: [sv-ec] 10.5.3 The foreach loop
>>
>>
>>> From: "danielm" <danielm@aldec.com.pl>
>>> Chapter about foreach loop defines that with such loop we 
>> may iterate 
>>> over dynamic arrays but it doesn't precise what should 
>> happend if size 
>>> of such array will change inside lthat oop.
>> This was addressed in the proposal for Mantis 1306, which 
>> specified that the results are undefined in that case, and 
>> that invalid index values may be generated.
>>
>> Presumably an implementation would either evaluate the size 
>> after each iteration, or once before starting the loop for efficiency.
>>
>>
>>> Same about associative array what should happen if we add or remove 
>>> some entries from such table inside foreach.
>> You are right that the LRM does not specify this.  It could 
>> be inferred to be similarly undefined.
>>
>> Presumably an implementation would use the built-in methods 
>> to perform the iteration.  So an entry added before the 
>> current entry would not be iterated over, but an entry added 
>> after it would.  Removing an entry that is after the current 
>> entry would cause it not to be iterated over.
>> Removing the current entry would prevent further iteration.
>>
>>
>> Steven Sharp
>> sharp@cadence.com
>>
>>
>> --
>> This message has been scanned for viruses and dangerous 
>> content by MailScanner, and is believed to be clean.
>>
>>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jan 22 16:52:07 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 22 2008 - 16:52:42 PST