Hmm. We're getting into "distant memory" here, so I could very well
be wrong.
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
way. :-\
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
"valid"?
Ralph
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
