On Sun, Apr 3, 2011 at 2:12 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Dan McGee <dpmcgee@xxxxxxxxx> writes:
>
>> diff --git a/color.h b/color.h
>> index c0528cf..a7da793 100644
>> --- a/color.h
>> +++ b/color.h
>> @@ -53,6 +53,10 @@ struct strbuf;
>> Â */
>> Âextern int git_use_color_default;
>>
>> +extern const char *column_colors_ansi[13];
>> +
>> +/* Ignore the RESET at the end when giving the size */
>> +#define COLUMN_COLORS_ANSI_MAX (ARRAY_SIZE(column_colors_ansi) - 1)
>
> Sneaky.
>
> I first went "Huh? -- this array-size macro cannot work", expecting that
> the array is not decleared with a fixed size in the header.
>
> It may make sense to unify these two palettes whose slot assignment does
> not have any meaning, but it feels that the above change totally goes
> against the spirit of using ARRAY_SIZE() macro, the point of which is to
> liberate programmers from having to count and adjust the size when adding
> the contents to the array.
>
> Wouldn't it make more sense to do something like
>
> Â Â>>> in the header <<<
> Â Âextern const char *custom_colors_ansi[];
> Â Âextern const int CUSTOM_COLORS_ANSI_MAX;
>
> Â Â>>> in the code <<<
> Â Âconst char *custom_colors_ansi[] = {
> Â Â Â Â Â Â... as before ...
> Â Â};
> Â Â/* Does not count the last element "RESET" */
> Â Âconst int CUSTOM_COLORS_ANSI_MAX = ARRAY_SIZE(custom_colors_ansi) - 1;
>
> to avoid mistakes?
Duh. This makes way more sense, I'll resend the patch with the
necessary changes; I couldn't think of an elegant way to do it at the
time.
On another note, we also have this whole crazy "- 1" bit and the RESET
element at the end, and yet I see nowhere that slot is actually used.
It looks like this was introduced by commit 1e3d4119d21df28.
-Dan
--
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