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
13 matches
Mail list logo
