Han-Wen Nienhuys writes:
>> @@ -84,6 +86,9 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>> for (i = 0; i < ARRAY_SIZE(keywords); i++) {
>> struct keyword_entry *p = keywords + i;
>> int len = strlen(p->keyword);
>>
Jeff King writes:
>> In the longer term we may want to accept size_t as parameter for
>> clarity (even though we know that a sideband message we are painting
>> typically would fit on a line on a terminal and int is sufficient).
>> Write it down as a NEEDSWORK comment.
>
> This "typically" made m
On Sat, Aug 18, 2018 at 6:16 PM Junio C Hamano wrote:
> > Actually, let's just lose the conditional. strbuf_add() would catch
> > and issue an error message when it notices that we fed negative
> > count anyway ;-).
>
> So I'll have this applied on top of the original topic to prevent a
> buggy v
and, thanks for cleaning up after me :)
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
On Sat, Aug 18, 2018 at 09:16:28AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] sideband: do not read beyond the end of input
>
> The caller of maybe_colorize_sideband() gives a counted buffer
> , but the callee checked src[] as if it were a NUL terminated
> buffer. If src[] had al
Junio C Hamano writes:
> Junio C Hamano writes:
>
- strbuf_add(dest, src, n);
+ if (0 < n)
+ strbuf_add(dest, src, n);
>>>
>>> This check seems unnecessary. strbuf_add can cope fine with !n.
>>
>> I was primarily interested in catching negatives, and !n was a mere
>> o
Jonathan Nieder writes:
> And here are some tests to squash in.
Thanks, will do.
Junio C Hamano writes:
>>> - strbuf_add(dest, src, n);
>>> + if (0 < n)
>>> + strbuf_add(dest, src, n);
>>
>> This check seems unnecessary. strbuf_add can cope fine with !n.
>
> I was primarily interested in catching negatives, and !n was a mere
> optimization, but you are correct
Jonathan Nieder writes:
>> --- a/sideband.c
>> +++ b/sideband.c
>> @@ -75,7 +75,7 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>
> Not about this patch: should the 'n' parameter be a size_t instead of
> an int? It doesn't matter in practice (since the c
Junio C Hamano wrote:
> Subject: sideband: do not read beyond the end of input
>
> The caller of maybe_colorize_sideband() gives a counted buffer
> , but the callee checked *src as if it were a NUL terminated
> buffer. If src[] had all isspace() bytes in it, we would have made
> n negative, and t
(-cc: my @google.com email)
Hi,
Junio C Hamano wrote:
> Subject: sideband: do not read beyond the end of input
>
> The caller of maybe_colorize_sideband() gives a counted buffer
> , but the callee checked *src as if it were a NUL terminated
> buffer. If src[] had all isspace() bytes in it, we wo
Junio C Hamano writes:
> This loop can run out of bytes in src in search of non-space before
> n gets to zero or negative, and when that happens ...
>
>> +for (i = 0; i < ARRAY_SIZE(keywords); i++) {
>> +struct keyword_entry *p = keywords + i;
>> +int len = strlen(p->k
Han-Wen Nienhuys writes:
> +/*
> + * Optionally highlight one keyword in remote output if it appears at the
> start
> + * of the line. This should be called for a single line only, which is
> + * passed as the first N characters of the SRC array.
> + */
> +static void maybe_colorize_sideband(str
The colorization is controlled with the config setting "color.remote".
Supported keywords are "error", "warning", "hint" and "success". They
are highlighted if they appear at the start of the line, which is
common in error messages, eg.
ERROR: commit is missing Change-Id
The Git push process
14 matches
Mail list logo
