Nicolas Pitre <nico@xxxxxxx> wrote: > On Fri, 31 Oct 2008, Shawn O. Pearce wrote: > > > > 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. > > Actually, the pointer-returning functions can encode error cases into a > "negative" pointer. See include/linux/err.h for example. > > void *ptr = git_alloc_foo(...); > if (IS_ERR(ptr)) > die("git_alloc_foo failed: %s", git_strerr(PTR_ERR(ptr))); Oh, good point. We could also stagger the errors so they are always odd, and never return an odd-alignment pointer from a successful function. Thus IS_ERR can be written as: #define IS_ERR(ptr) (((intptr_t)(ptr)) & 1) which is quite cheap, and given the (probably required anyway) aligned allocation policy means we still have 2^31 possible error codes available. -- 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