From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDZwK-0001c9-0V for qemu-devel@nongnu.org; Mon, 17 Sep 2012 07:56:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDZwF-0006Op-S4 for qemu-devel@nongnu.org; Mon, 17 Sep 2012 07:56:35 -0400 From: Markus Armbruster References: <1347873003-11593-1-git-send-email-lersek@redhat.com> Date: Mon, 17 Sep 2012 13:56:27 +0200 In-Reply-To: <1347873003-11593-1-git-send-email-lersek@redhat.com> (Laszlo Ersek's message of "Mon, 17 Sep 2012 11:10:03 +0200") Message-ID: <87k3vsoob8.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] TextConsole: saturate escape parameter in TTY_STATE_CSI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org Laszlo Ersek writes: > Signed-off-by: Laszlo Ersek > --- > Build tested. > console.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/console.c b/console.c > index c1ed5e0..67080f4 100644 > --- a/console.c > +++ b/console.c > @@ -938,8 +938,11 @@ static void console_putchar(TextConsole *s, int ch) > case TTY_STATE_CSI: /* handle escape sequence parameters */ > if (ch >= '0' && ch <= '9') { > if (s->nb_esc_params < MAX_ESC_PARAMS) { > - s->esc_params[s->nb_esc_params] = > - s->esc_params[s->nb_esc_params] * 10 + ch - '0'; > + int *param = &s->esc_params[s->nb_esc_params]; > + int digit = (ch - '0'); > + > + *param = (*param <= (INT_MAX - digit) / 10) ? > + *param * 10 + digit : INT_MAX; > } > } else { > if (s->nb_esc_params < MAX_ESC_PARAMS) Before this patch, silent integer overflow. Exact behavior depends on hosts int type. For instance, \e[4294967296 is the same as \e[0 with 32 bit int, but with 64 bit int. What does a real vt100 do? I don't have one anymore. For what it's worth, both xterm and Xfce Terminal appear to saturate at some "big" number ("big" compared to the argument values that are actually useful; INT_MAX should do fine). In particular, \e[4294967296 does *not* behave like \e[0. Therefore, changing QEMU to saturate makes sense. Reviewed-by: Markus Armbruster