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@us.ibm.com