Quoth Gary Mills on Fri, Apr 03, 2009 at 07:42:25PM -0700: > > All error codes should be documented. > > I agree. I've certainly seen problems arise when library functions or system > calls > return unexpected error codes. In this case, the full list of return codes > appears > in scf_error(3SCF). In my review, I can't rule any of them out for being > returned > from the mid-level functions in unusual circumstances. However, the logic of > these > functions suggests a much smaller set of outcomes. Some return codes in the > full > set don't make sense for these functions.
True, "all error codes" depends on assumptions about how adversarial the environment is. I don't think it's necessary to document error codes which would arise from a memory error on the stack (since then any code could be returned), but I do think errors for memory corruption in data structures should be documented (since those could be caused by the library consumer). And in this case we communicate with svc.configd, which we don't necessarily know is the official Solaris one. I believe in most cases I assert() if we receive an unexpected error code from svc.configd (to help catch bugs in svc.configd), but I think it would also be reasonable to return SCF_ERROR_INTERNAL. Though maybe the behavior should be selectable by NDEBUG or an environment variable. > Aggregating SCF_ERROR_DELETED > with SCF_ERROR_NOT_FOUND makes sense in that context. I'm certainly willing > to write the code for that change, as a way to get started as a contributer. Ok, request a sponsor on request-sponsor at opensolaris.org . David
