Received: by 10.223.185.116 with SMTP id b49csp3966478wrg; Mon, 26 Feb 2018 08:59:33 -0800 (PST) X-Google-Smtp-Source: AH8x225zsEEuO6CDCTboD4BsyWcMA5WEuV0UvhT6bhx5o2/3NxIOsKiXs1pRRJ4BFZtIxeTpMJAC X-Received: by 10.99.96.18 with SMTP id u18mr9198224pgb.124.1519664373652; Mon, 26 Feb 2018 08:59:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519664373; cv=none; d=google.com; s=arc-20160816; b=keUt7ftSJgbSdN8YOHdq9GUs3uqi9a0CJKwd2VPjsqvmR5RFzJa/PVZEEg/L0hmBQv XppGNZ4otu7v6TVQOKhc9AiS9Jyzh+g1xyF+UnGp8y3fyZoZ6HHNOK9H3e249VvUTLx6 9oYEQRYRB6rV9fLy33ijkXCb/sxuMFwJOhOZTtOsnmdN/EwvR5/HeLrewLwWtDwr0IPR xGdxhQfwojaneUfPKDVSMDOje4HOCkCt8Fa/ymc0nPlKJLirf6R313YyQlxJeWhi/P2Z lputuKlxZ/qnVfePnIEOMnISBVuIzulIBFjCpwftMAhQxJqvoQCbgFrSPTgVwyEUmbLn OqtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=6uCRu+fs6ii31mavTlVYVgs0KMqdyGaxpZNjG+Tw8yc=; b=M44dSxrigmx2L26QcuNGNqyu0PSsGaGRXhkYtrW8KPz8/Hnq3PC5mNeFd3FGk5aVC4 +1poHoXiuH5tl7jMsAYZ1CEuhRe6jhR/n16wW08FKaadZ/lWCZr11RHIELGeefEKxVbh oWgKfRjB2PuTy2r3lx/h6D6Thewo1c9Vx6ELpI1kLchzoXVmq+cgSZ51/OdPkUn0oLyJ MPXP41tmHuOjZoLfkcxP4RCmeKJWL+7hP8rqhIfuNB/ahnPNC0CQ8UrFtXdGZ5hUjGXP wYGOjt0k35iir3qogKV20GABv60u2Hg3cAvMAqU226P+c1lObnsYwarvvpN5kXJvhHLE +E7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JgYno3IZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h6-v6si7021430pln.198.2018.02.26.08.59.16; Mon, 26 Feb 2018 08:59:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JgYno3IZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751550AbeBZQ5i (ORCPT + 99 others); Mon, 26 Feb 2018 11:57:38 -0500 Received: from mail-qk0-f196.google.com ([209.85.220.196]:33918 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018AbeBZQ5g (ORCPT ); Mon, 26 Feb 2018 11:57:36 -0500 Received: by mail-qk0-f196.google.com with SMTP id l206so19892601qke.1 for ; Mon, 26 Feb 2018 08:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6uCRu+fs6ii31mavTlVYVgs0KMqdyGaxpZNjG+Tw8yc=; b=JgYno3IZmsRPsJa3gsGHhflkZlWhUxpPMyJHGGZjZW3IFxLu91vzNtuyWk3w89HTLG jauTPJX1l0CKB9wgUITBTaJzUJ4aMy+OTnD+ipC8stXk50B6Q09CvORuqDbr36UN3N4j LIyjZXGiMr0DY7NrzWFimPaqMcdPHcY59OJ6Tx3eeIoHEVHl/3L/sQuNKyU9AWfwGI/6 9NOmuFQCqzy4+RKZ+ALYPj2BSoX/qbK0zvNVdQnMriDm8bpik9F80xh682rBE88NUh0F /wAL1PmUC8jw1OP7IRiaiN87xCGhOYBltL/lPGmmDQZgJ3CHdQ7nHpuk0nwFcvR8AZjy xg+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6uCRu+fs6ii31mavTlVYVgs0KMqdyGaxpZNjG+Tw8yc=; b=DhVL4Or/yrTilq0WBc5/udFeJ7Cf8M7z7Gatbwfw/AH5MCvI4pOaD3/YSG6jAlgjey Ly3s7QVBSAD9HFgRllp60pBaoyNHp1c+Xh4D7aVQwTb494zm4Fxt/+4YJxDHlsQyjH0G psXnCNGC/LJQyeZsIi49PMmC0FJlQkgqwWFaNbEHvQ0lhn7ZsLKZ6v4xdABlKjUbbjv5 vcld5DXpYWzFdddDYQPyh2nILjf+hieRwM3Z/wwPI0JIH76RydDIBu6cuLDkQl3uiCcT xzn1MCm64sPaIhNmCxcC6Jm/DoTay00gvTz9ekQkObYJc+lpOVmJ49HlmZEa0mpv36J/ ml8Q== X-Gm-Message-State: APf1xPA8UAQB/C60o0jCWfSsFJ0UA8tsdzkvDwCb+gKCF+d+2++BALx9 VuRIxvF2bb760EAKXiESzmNOxpBRrhHjg3pnWFQ= X-Received: by 10.55.46.194 with SMTP id u185mr17547898qkh.63.1519664256208; Mon, 26 Feb 2018 08:57:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.52.247 with HTTP; Mon, 26 Feb 2018 08:57:15 -0800 (PST) In-Reply-To: References: <9ec3c54c-f8fe-22d7-783e-8cf9862405bb@robertabel.eu> <20180225235432.31209-1-rabel@robertabel.eu> <20180225235432.31209-2-rabel@robertabel.eu> <20180225235432.31209-3-rabel@robertabel.eu> <20180225235432.31209-4-rabel@robertabel.eu> From: Miguel Ojeda Date: Mon, 26 Feb 2018 17:57:15 +0100 Message-ID: Subject: Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands To: Robert Abel Cc: linux-kernel , Willy Tarreau , Geert Uytterhoeven , Andy Shevchenko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 26, 2018 at 5:49 PM, Miguel Ojeda wrote: > On Mon, Feb 26, 2018 at 12:54 AM, Robert Abel wrote: >> NUL-terminate each individual number to be parsed. >> To do this, the next command character and a pointer to its argument >> are found and stored. The command character is then overwritten by NUL >> before kstr* functions are called on the buffer. > > It would be useful to have this description in the code itself as a comment. > >> >> Signed-off-by: Robert Abel >> --- >> drivers/auxdisplay/charlcd.c | 53 ++++++++++++++++++++++++++++++++++++-------- >> 1 file changed, 44 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c >> index a3d364e6c666..24cabe88c7f0 100644 >> --- a/drivers/auxdisplay/charlcd.c >> +++ b/drivers/auxdisplay/charlcd.c >> @@ -471,28 +471,63 @@ static inline int handle_lcd_special_code(struct charlcd *lcd) >> break; >> } >> case 'x': /* gotoxy : LxXXX[yYYY]; */ >> - case 'y': /* gotoxy : LyYYY[xXXX]; */ >> + case 'y': { /* gotoxy : LyYYY[xXXX]; */ >> + > > Extra empty line. > >> + char* nxt_esc; >> + char nxt_cmd; > > I think skipping the "e" in the names do not buy us much :) > >> + char cmd; >> + struct charlcd_priv_addr tmp_addr; >> + >> if (!strchr(esc, ';')) >> break; >> >> - while (*esc) { >> - if (*esc == 'x') { >> - esc++; >> - if (kstrtoul(esc, 10, &priv->addr.x) < 0) >> + /* sequence is processed whether legal or illegal */ >> + processed = 1; >> + >> + /* copy current address to temporary buffer */ >> + tmp_addr = priv->addr; >> + >> + nxt_cmd = *esc++; >> + nxt_esc = esc; >> + >> + while ('\0' != *esc) { > > Please do not change the style of the code w.r.t to the rest of the > file, which writes tests with the non-lvalue on the right-hand side > and do not compare against '\0'. Same for the rest. > >> + > > Extra empty line. > >> + cmd = nxt_cmd; >> + esc = nxt_esc; >> + nxt_esc = strpbrk(esc, "xy;"); >> + if (NULL != nxt_esc) { >> + nxt_cmd = *nxt_esc; >> + /* terminate current sequence with NUL */ >> + *nxt_esc++ = '\0'; >> + } >> + >> + if ('x' == cmd) { >> + if (kstrtoul(esc, 10, &tmp_addr.x) < 0) >> break; >> - } else if (*esc == 'y') { >> - esc++; >> - if (kstrtoul(esc, 10, &priv->addr.y) < 0) >> + } else if ('y' == cmd) { >> + if (kstrtoul(esc, 10, &tmp_addr.y) < 0) >> break; >> } else { >> + /* break on unknown command or ';' */ >> break; >> } > > { } not needed (your patch doesn't touch this -- just pointing it out). Disregard this one, just checked and coding-style.rst specifies one must use braces if the other branches need to use them. Cheers, Miguel > >> + >> } >> >> + /* unknown commands in sequence will be followed by at least ';' */ >> + if ('\0' != *esc) >> + break; >> + >> + /* clamp new x/y coordinates */ >> + if (tmp_addr.x >= lcd->width) >> + tmp_addr.x = lcd->width - 1; > > tmp_addr.x = min(tmp_addr.x, lcd->width - 1); > >> + tmp_addr.y %= lcd->height; >> + >> + priv->addr = tmp_addr; >> charlcd_gotoxy(lcd); >> - processed = 1; >> break; >> } >> + } > > On a general note, the code seems a bit convoluted for what it does, > specially without the comment written in the commit message :-) Isn't > it simpler to use a tiny array in the stack and put the numbers to be > converted instead of modifying the input sequence and dancing with > pointers? > > Thanks for the patch! > > Cheers, > Miguel > >> >> /* TODO: This indent party here got ugly, clean it! */ >> /* Check whether one flag was changed */ >> -- >> 2.11.0 >>