On Sat, 17 Mar 2007 22:52:52 -0700
Junio C Hamano <junkio@cox.net> wrote:

| "Shawn O. Pearce" <spearce@spearce.org> writes:
| 
| > Take a look at sha1_file.c, open_packed_git_1:
| >
| > ...
| >     if (!pack_version_ok(hdr.hdr_version))
| >         return error("packfile %s is version %u and not supported"
| >             " (try upgrading GIT to a newer version)",
| >             p->pack_name, ntohl(hdr.hdr_version));
| > ...
| >
| > Here we are supplying a lot more than just a simple error code
| > that can be mapped to a static string.
| >
| > Of course that code is currently feeding it to the error function,
| > which today calls the error_routine (see usage.c).  We could buffer
| > the strings sent to error()/warn() and let the caller obtain all
| > strings that occurred during the last API call.
| 
| Actually, since we are talking about the error path,
| 
|  (1) we do not care performance of what happens there that much, but
|  (2) we *do* care about not doing extra allocation.
| 
| So it might make sense to have a preallocated "error string"
| buffer, sprintf the error message in there and return error
| codes.

 Other possibility is to let the caller do the job.

 I mean, if the information needed to print the error message (packfile
name and version in this example) is available to the caller, or the
caller can get it someway, then the caller could check which error
he got and build the message himself.

 That seems simpler to me, considering the caller has the needed
info, of course...


-- 
Luiz Fernando N. Capitulino
-
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