Nicolas Pitre <nico@cam.org> wrote:
quoted text
> 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.
 
quoted text
> > 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html