Subject: Re: Libification project (SoC)

From: "Shawn O. Pearce" <[email-masked]>
Date: Sun, 18 Mar 2007 01:23:32 -0400

"Luiz Fernando N. Capitulino" <[email-masked]> wrote:
> On Fri, 16 Mar 2007 19:16:46 -0400
> "Shawn O. Pearce" <[email-masked]> 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.