On Wed, Sep 14, 2016 at 09:19:01AM +0200, Jiri Slaby wrote:
> On 09/14/2016, 08:28 AM, Adam Borowski wrote:
> > This makes it show up on UBSAN:
> > perl -e 'for (0..15) {my @x=("0")x$_;push @x,qw(38 2 64 128 192 4);printf
> > "\e[%smAfter %d zeroes.\e[0m\n", join(";",@x[0..($_+5<15?$_+5:15)]), $_}'
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 2705ca9..b51586f 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -1316,7 +1316,7 @@ static int vc_t416_color(struct vc_data *vc, int i,
> > /* 256 colours -- ubiquitous */
> > i++;
> > rgb_from_256(vc->vc_par[i], &c);
> > - } else if (vc->vc_par[i] == 2 && i <= vc->vc_npar + 3) {
> > + } else if (vc->vc_par[i] == 2 && i + 3 <= vc->vc_npar) {
>
> Definitely makes sense. But we are still off-by-one, if I am looking
> correctly. It should be "i + 3 < npar", right?
Nope, npar is really "last parameter" rather than "number of parameters",
thus it needs to be compared <= rather than <. Everywhere else in the file,
with one exception, it is compared thusly.
But, it's not the first time this has caused confusion. I guess that one
exception, right in the previous "if", is misleading, and it would be good
to deoptimize it to "i+1 <= npar" for consistency.
Let's do so (patch follows).
--
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week. Protect your ARMs, folks!
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
