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

Re: [PATCH v8 03/12] Move lower case functions into wrapper.c

From
Jeff King <peff@peff.net>
Date
Mar 27, 2014, 22:34 UTC
Message-ID
<20140327223406.GA32434@sigill.intra.peff.net>
In-Reply-To
<xmqqlhvvcmnj.fsf@gitster.dls.corp.google.com>
On Thu, Mar 27, 2014 at 03:16:48PM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> > I wasn't looking at the caller (and I haven't).  I agree that, if
> > you have to compare case-insensitive user input against known set of
> > tokens, using strcasecmp() would be saner than making a downcased
> > copy and the set of known tokens.  I do not know however you want to
> > compare in a case-insensitive way in your application, though.
> 
> It appears that one place this "lowercase" is used is to allow
> rAnDOm casing in the configuration file, e.g.
> 
> 	[trailer "Signed-off-by"]
> 		where = AfTEr
> 
> which I find is totally unnecessary.  Do we churn code to accept
> such a nonsense input in other places?
I think we are very inconsistent.

All bool config values allow "tRuE". Ones that take "auto" often use strcasecmp (e.g., diff.*.binary). "blame.date" and "help.format" choose from a fixed set of tokens, but use strcmp.

Command line parameters are of course case-sensitive, and tokens used by them usually are, too (e.g., the date formats for "blame.date" or also the same ones taken by "--date=").

In general I do not see any reason _not_ to use strcasecmp for config values that are matching a fixed set. It's friendlier to the user, the extra CPU time is negligible, and the code is no harder to read than a strcmp. Just looking at the callers in patch 04/12, I think it would be better just used strcasecmp instead of making a lowercase copy. Not because the copy is wasteful (it is, but it almost certainly doesn't matter here), but because avoiding the copy is shorter and easier to follow (you don't have to wonder about memory ownership).

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 of 27 in “Add interpret-trailers builtin”
  1. 00/12 Add interpret-trailers builtinChristian Couder, Mar 26, 2014
  2. 01/12 Add data structures and basic functions for commit trailersChristian Couder, Mar 26, 2014
  3. Junio C HamanoMar 26, 2014
  4. Christian CouderMar 27, 2014
  5. 02/12 trailer: process trailers from stdin and argumentsChristian Couder, Mar 26, 2014
  6. 03/12 Move lower case functions into wrapper.cChristian Couder, Mar 26, 2014
  7. Junio C HamanoMar 26, 2014
  8. Christian CouderMar 27, 2014
  9. Junio C HamanoMar 27, 2014
  10. Junio C HamanoMar 27, 2014
  11. Jeff KingMar 27, 2014
  12. Junio C HamanoMar 27, 2014
  13. Jeff KingMar 27, 2014
  14. Junio C HamanoMar 28, 2014
  15. Jeff KingMar 28, 2014
  16. Christian CouderMar 28, 2014
  17. 04/12 trailer: read and process config informationChristian Couder, Mar 26, 2014
  18. 05/12 trailer: process command line trailer argumentsChristian Couder, Mar 26, 2014
  19. 06/12 trailer: parse trailers from stdinChristian Couder, Mar 26, 2014
  20. 07/12 trailer: put all the processing together and printChristian Couder, Mar 26, 2014
  21. 08/12 trailer: add interpret-trailers commandChristian Couder, Mar 26, 2014
  22. 09/12 trailer: add tests for "git interpret-trailers"Christian Couder, Mar 26, 2014
  23. 10/12 trailer: execute command from 'trailer.<name>.command'Christian Couder, Mar 26, 2014
  24. 11/12 trailer: add tests for commands in config fileChristian Couder, Mar 26, 2014
  25. 12/12 Documentation: add documentation for 'git interpret-trailers'Christian Couder, Mar 26, 2014
  26. Junio C HamanoMar 26, 2014
  27. Christian CouderMar 27, 2014

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.