Tom Whitten writes: > David Bustos writes: > > Quoth Tom Whitten on Tue, Dec 16, 2008 at 01:18:20PM -0700: > > > Ah. I see what your driving at. My inclination is to remove the assert > > > and let the error return percolate back up to the callers. I've checked > > > the tree of callers to verify that they properly handle this return. I > > > also checked to see how the return is propagated back to libscf, and > > > verified that callers of the library functions also properly handled the > > > error return as it gets mapped. > > > > Ok, but please tell me more about your inclination: Do you know how np's > > FMRI might be longer than REP_PROTOCOL_FMRI_LEN? My feeling is that > > since REP_PROTOCOL_FMRI_LEN is computed from the maximum legal name > > lengths, the existance of such a node indicates either a bug in the > > node-creation code, or memory corruption. > > > > > > David > > Yes. You are correct. >
David, I've been thinking more about this. I think that the proper way to handle this is to have rc_node_get_fmri_or_fragment() call bad_error() if the caller does not provide a sufficiently large buffer. I think that this is cleaner than having callers of rc_node_get_fmri_or_fragment() doing asserts. I think this change, however, should be the subject of a new bug which I will file if you concur. I would fix the new bug after I get the putback done for the current set of bugs. My logic here is that people are encountering the current set of bugs, so I would like to get these fixes back into Nevada. tom
