KR> Change result_list to tmp_list since the list is freed before
KR> filter_results() returns.
Thanks :)
KR> Initialize CMPIStatus s in do_assoc(). If match class fails, then
KR> s is never properly set. This is assuming that it's *not* an
KR> error if a user queries an association with a result class that
KR> isn't handled by the provider.
If they try to pass an invalid reference (i.e. one we don't support an
association for) we RETURN_UNSUPPORTED(). Shouldn't we do the same
thing if they ask for a result that we don't support a transition to?
Rather, shouldn't these two cases behave the same, no matter what that
behavior should be?
KR> The CU_DEBUG() call before the match_class() call on
KR> info->assoc_class has a typo. The string text prints
KR> info->assoc_class, but the value passed in for info->assoc_class
KR> is info->result_class.
That wouldn't be confusing in a debug situation at all, would it? :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com