Hmm. We're getting into "distant memory" here, so I could very well
But I *thought* that the original array implementation would return a
0 or a -1. It's possible that in the value_array consolidation that
this behavior was lost...? I'm not sure.
Other than that, I can't think of a good reason why we did it that
On Feb 24, 2009, at 9:48 PM, Ralph Castain wrote:
> I recently spent several days attempting to track down a bug in the
> trunk, finally finding that the root cause was linked to a rather
> strange behavior of the opal_value_array class.
> If you call opal_value_array_get_item and request an index that is
> beyond that of the current size of the array, this function will
> automatically increase the size of the value array, and return
> whatever garbage is sitting in the expanded memory location. There
> is no warning this has happened - no error code is returned, the
> memory is not zero'd, etc. What you get back may be
> indistinguishable from a "real", albeit nonsensical, value.
> Can someone explain why this behavior was considered desirable? It
> was clearly a designed response - I simply cannot see -why- we would
> want this behavior. If you request a value outside the bound of the
> array, what purpose is served by returning garbage as if it were
> devel mailing list