Re: libgit2 - a true git library

From: Shawn O. Pearce <spearce@spearce.org>
Date: Nov 1, 2008, 01:19 UTC
Message-ID: <20081101011910.GH14786@spearce.org>
In-Reply-To: <alpine.LFD.2.00.0810312106310.13034@xanadu.home>

Nicolas Pitre <nico@cam.org> wrote:

Show 8 quoted lines

> 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.

Show 7 quoted lines

> > 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.