[sv-bc] Default initial values

From: Jonathan Bromley <jonathanbromley@ymail.com>
Date: Sun Nov 07 2010 - 10:55:25 PST

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.
Received on Sun Nov 7 10:56:14 2010

This archive was generated by hypermail 2.1.8 : Sun Nov 07 2010 - 10:58:55 PST