Nicolas Pitre <nico@xxxxxxx> wrote: > On Fri, 31 Oct 2008, Shawn O. Pearce wrote: > > > I'm tempted to stick with int for the result type, but I don't > > want readers to confuse our result type of 0 == success, <0 == > > failure with some case where we return a signed integral value as > > a result of a computation. > > Does this actually happen ? Sometimes, but yea, its not that often. I think we've already settled that it shall be "int". I'm updating some stuff like that (and dropping _t) as I write this email. > > I'm also debating the error handling. Do we return the error > > code as the return value from the function, or do we stick it into > > some sort of thread-global like classic "errno", or do we ask the > > application to pass in a structure to us? > > Passing a structure pointer for errors is adding overhead to the API in > all cases, please don't do that. Agreed. Not going there. > Both the negative code and errno style are lightweight in the common "no > error" case. The errno style is probably more handy for those functions > returning a pointer which should be NULL in the error case. I'm sticking with return a negative code for now, to the extent that some functions which return a pointer but also have many common failure modes (e.g. git_odb_open) use an output parameter as their first arg, so the error code can be returned as the result of the function. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
