[Libvirt-cim] [PATCH 2 of 3] [RFC][CU] Add EI CIMXML parser

Dan Smith danms at us.ibm.com
Mon Feb 11 18:34:45 UTC 2008


KR> Should this be CMPI_null?  I know they're equivalent, but it might be
KR> good to use CMPI_null for clarity (and the unlikely chance that the
KR> value for CMPI_null is changed)

Yes, it should.  I changed the signature of that function (about 1000
times) and forgot to update that return.

KR> Should we use some kind of found flag here?  What if val_arr->type
KR> never equals XML_ELEMENT_NODE.  Then we pass the last value of
KR> val_arr to the function below, even if the element type doesn't
KR> equal XML_ELEMENT_NODE.

Technically the next call will fail appropriately, but yes, it should
be handled better.

KR> For these statements above, should we set s.rc to some kind of error
KR> return code?  Otherwise, we are returning a non-initialized status.

Yes :)

KR> Just a style note, but for non-boolean variables, aren't we trying to
KR> use something like:  (iptr != NULL)?

Yes :)

KR> The return status isn't caught here.  parse_instance() could
KR> return something other than CMPI_RC_OK if CMNewObjectPath() or
KR> CMNewInstance() fail.

Yep, that's broken indeed.

KR> I know this just and RFC, but don't forget to remove printfs or
KR> convert them to CU_DEBUGs. =)

Gah!  Every...Single...Time... :)

Thanks!

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20080211/486c5b51/attachment.sig>


More information about the Libvirt-cim mailing list