git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Libification project (SoC)

From
LCLuiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Date
Mar 17, 2007, 19:58 UTC
Message-ID
<20070317195832.2af87c06@home.brethil>
In-Reply-To
<20070316231646.GB4508@spearce.org>

On Fri, 16 Mar 2007 19:16:46 -0400 "Shawn O. Pearce" <spearce@spearce.org> wrote:

| "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> wrote:
| >  I think the right solution is to get rid of die() from functions that
| > are supposed to be an interface, set errno if needed and return -1
| > or NULL.
| 
| 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.
 Exactly!
 One simple example of an important error message that would be
lost can be found in read-cache.c:read_cache_from():
 o index file smaller than expected
 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);
	}
}
"""
 Instead of calling strerror() directly for error generated
when inserting a module, the insmod() function calls insert_moderror()
which provides the desirable mapping.
 I think we could have something like that for each git's
module, eg, git_cache_strerror(), git_commit_strerror() and so on.
 Does this look reasonable?
-- 
Luiz Fernando N. Capitulino
Previous: Shawn O. PearceNext: Shawn O. Pearce
Message 49 of 62 in “Libification project (SoC)”
  1. Luiz Fernando N. CapitulinoMar 16, 2007
  2. Shawn O. PearceMar 16, 2007
  3. Junio C HamanoMar 16, 2007
  4. Shawn O. PearceMar 16, 2007
  5. Junio C HamanoMar 16, 2007
  6. Johannes SchindelinMar 16, 2007
  7. Rocco RutteMar 16, 2007
  8. Johannes SchindelinMar 16, 2007
  9. Nicolas PitreMar 16, 2007
  10. Johannes SchindelinMar 16, 2007
  11. Nicolas PitreMar 16, 2007
  12. Steve FrécinauxMar 16, 2007
  13. Nicolas PitreMar 16, 2007
  14. Petr BaudisMar 18, 2007
  15. Johannes SchindelinMar 16, 2007
  16. Shawn O. PearceMar 16, 2007
  17. Marco CostalbaMar 16, 2007
  18. Marco CostalbaMar 16, 2007
  19. Nicolas PitreMar 16, 2007
  20. Marco CostalbaMar 16, 2007
  21. Johannes SchindelinMar 16, 2007
  22. Marco CostalbaMar 17, 2007
  23. Johannes SchindelinMar 17, 2007
  24. Andy ParkinsMar 16, 2007
  25. Petr BaudisMar 18, 2007
  26. Johannes SchindelinMar 18, 2007
  27. Petr BaudisMar 19, 2007
  28. Johannes SchindelinMar 19, 2007
  29. Theodore TsoMar 19, 2007
  30. Shawn O. PearceMar 19, 2007
  31. Johannes SchindelinMar 19, 2007
  32. Linus TorvaldsMar 19, 2007
  33. Linus TorvaldsMar 19, 2007
  34. Andreas EricssonMar 21, 2007
  35. Linus TorvaldsMar 21, 2007
  36. Andreas EricssonMar 22, 2007
  37. Marco CostalbaMar 19, 2007
  38. Steve FrécinauxMar 19, 2007
  39. Steve FrécinauxMar 19, 2007
  40. Johannes SchindelinMar 19, 2007
  41. Petr BaudisMar 19, 2007
  42. Johannes SchindelinMar 19, 2007
  43. Marco CostalbaMar 19, 2007
  44. Petr BaudisMar 16, 2007
  45. Luiz Fernando N. CapitulinoMar 16, 2007
  46. Petr BaudisMar 16, 2007
  47. Luiz Fernando N. CapitulinoMar 16, 2007
  48. Shawn O. PearceMar 16, 2007
  49. Luiz Fernando N. CapitulinoMar 17, 2007
  50. Shawn O. PearceMar 18, 2007
  51. Junio C HamanoMar 18, 2007
  52. Luiz Fernando N. CapitulinoMar 18, 2007
  53. Junio C HamanoMar 18, 2007
  54. Luiz Fernando N. CapitulinoMar 19, 2007
  55. Nicolas PitreMar 18, 2007
  56. Johannes SchindelinMar 16, 2007
  57. Johannes SixtMar 16, 2007
  58. Matthieu MoyMar 16, 2007
  59. Johannes SchindelinMar 16, 2007
  60. Petr BaudisMar 16, 2007
  61. Jakub NarebskiMar 17, 2007
  62. Shawn O. PearceMar 17, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.