"Luiz Fernando N. Capitulino" <lcapitulino@xxxxxxxxxxxxxxx> wrote:
> On Fri, 16 Mar 2007 19:16:46 -0400
> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> wrote:
> | And then make their callers (if they are above the public API layer)
> | die instead. In some cases this might imply an undesirable change
> | in the error message produced, as necessary details that are included
> | today would be unavailable in the caller.
>
> I've found a possible solution, though.
>
> Take a look at Rusty's solution for the same problem in
> module-init-tools:
>
> """
> /* We use error numbers in a loose translation... */
> static const char *insert_moderror(int err)
> {
> switch (err) {
> case ENOEXEC:
> return "Invalid module format";
> case ENOENT:
> return "Unknown symbol in module, or unknown parameter (see dmesg)";
> case ENOSYS:
> return "Kernel does not have module support";
> default:
> return strerror(err);
> }
> }
> """
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.
--
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