0002686: Ballot comment #69: Bit/Part-select errors should be reported uniformly.

Notes
(0007987) shalom (manager) 2009-04-13 04:37	See ballot comments 32 and 42.

(0008223) mmaidment (manager) 2009-05-13 10:01	On May 11, 2009 the SV-BC committee read and considered this feedback. The committee believes it is too broad for the scope of the draft to implement at this time but may be considered for future revisions.

(0008701) Dave Rich (manager) 2009-07-01 10:41	The Champions have voted unanimously to approve this issue on June 29, 2009

(0008836) Dave Rich (manager) 2009-07-02 14:59	The P1800-2009 Working group approved the resolution of this ballot item and will leave this issue open for the next PAR.

(0009246) Dave Rich (manager) 2010-02-05 15:57	There is a contradiction in the LRM in that the behavior of an out of bounds index is defined a few paragraphs above these notes. "A part-select that addresses a range of bits that are completely out of the address bounds of the vector, packed array, packed structure, parameter or concatenation, or a part-select that is x or z shall yield the value x when read and shall have no effect on the data stored when written. Part-selects that are partially out of range shall, when read, return x for the bits that are out of range and shall, when written, only affect the bits that are in range." So there is no need to make this an error if the behavior is defined.

(0009247) shalom (manager) 2010-02-07 00:52	There is a difference between the situation discussed in the description of this Mantis item, where an out-of-bounds index can be detected at compile-time, such as when the index is a constant expression, and the situation where the index is a variable expression and then the out-of-bounds reference occurs only at run-time. No one has argued that the behavior is undefined. Users have not complained (at least, not much) about out-of-bounds reads, where 4-state references return x or z (though 2-state references return 0). Mostly users have complained about out-of-bounds writes, where there is no error indication. They do not like the behavior currently defined in the LRM, where nothing happens. They want to get an error.

Issue History
Date Modified	Username	Field	Change
2009-04-13 04:35	shalom	New Issue
2009-04-13 04:35	shalom	Type	=> Enhancement
2009-04-13 04:35	shalom	Issue Monitored: shalom
2009-04-13 04:35	shalom	Relationship added	child of 0002685
2009-04-13 04:36	shalom	Relationship added	related to 0002680
2009-04-13 04:36	shalom	Relationship added	related to 0002682
2009-04-13 04:36	shalom	Relationship added	child of 0002356
2009-04-13 04:37	shalom	Note Added: 0007987
2009-05-13 10:01	mmaidment	Note Added: 0008223
2009-05-13 10:01	mmaidment	Status	new => resolved
2009-05-13 10:01	mmaidment	Resolution	open => suspended
2009-07-01 10:41	Dave Rich	Note Added: 0008701
2009-07-01 10:48	Dave Rich	Note Added: 0008752
2009-07-01 12:28	Dave Rich	Note Deleted: 0008752
2009-07-02 14:59	Dave Rich	Note Added: 0008836
2009-07-02 15:01	Dave Rich	Status	resolved => feedback
2010-02-05 15:57	Dave Rich	Note Added: 0009246
2010-02-07 00:52	shalom	Note Added: 0009247