color: fix max-size comment

We use fixed-size buffers for colors, because we know our
parsing cannot grow beyond a particular bound. However, our
comment description has two issues:

  1. It has the description in two forms: a short one, and
     one with more explanation. Over time the latter has
     been updated, but the former has not. Let's just drop
     the short one (after making sure everything it says
     is in the long one).

  2. As of ff40d18 (parse_color: recognize "no$foo" to clear
     the $foo attribute, 2014-11-20), the per-attribute size
     bumped to "3" (because "nobold" is actually "21;"). But
     that's not quite enough, as somebody may use both
     "bold" and "nobold", requiring 5 characters.

     This wasn't a problem for the final count, because we
     over-estimated in other ways, but let's clarify how we
     got to the final number.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pull/270/head
Jeff King 7 years ago committed by Junio C Hamano
parent 765428699a
commit 0111681ecf
  1. 12
      color.h

@ -3,18 +3,20 @@
struct strbuf;
/* 2 + (2 * num_attrs) + 8 + 1 + 8 + 'm' + NUL */
/* "\033[1;2;4;5;7;38;5;2xx;48;5;2xxm\0" */
/*
* The maximum length of ANSI color sequence we would generate:
* - leading ESC '[' 2
* - attr + ';' 3 * 10 (e.g. "1;")
* - attr + ';' 2 * num_attr (e.g. "1;")
* - no-attr + ';' 3 * num_attr (e.g. "22;")
* - fg color + ';' 17 (e.g. "38;2;255;255;255;")
* - bg color + ';' 17 (e.g. "48;2;255;255;255;")
* - terminating 'm' NUL 2
*
* The above overcounts attr (we only use 5 not 8) and one semicolon
* but it is close enough.
* The above overcounts by one semicolon but it is close enough.
*
* The space for attributes is also slightly overallocated, as
* the negation for some attributes is the same (e.g., nobold and nodim).
* We also allocate space for 6 attributes (even though we have only 5).
*/
#define COLOR_MAXLEN 70

Loading…
Cancel
Save