[sv-bc] RE: Default initial values

See Mantis 1067.

Shalom

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
> Sent: Sunday, November 07, 2010 8:55 PM
> To: Bresticker, Shalom; sv-ec@eda.org; sv-bc@eda.org
> Subject: 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
>

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