From: Shawn O. Pearce <spearce@spearce.org>
Date: Sat, 01 Nov 2008 01:52:17 GMT
Subject: Re: libgit2 - a true git library
Message-ID: <20081101015217.GJ14786@spearce.org>
In-Reply-To: <alpine.LFD.2.00.0810312135190.13034@xanadu.home>

Nicolas Pitre <nico@cam.org> 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.