Received: by 10.223.185.116 with SMTP id b49csp4283578wrg; Mon, 26 Feb 2018 14:44:59 -0800 (PST) X-Google-Smtp-Source: AH8x227gEzPtUY/nkVEa1aLmPc/t4FFEkxIq859Zy/xW6QwpewOabMV5yKgQv0asFgZHP+HsoL3f X-Received: by 2002:a17:902:b10b:: with SMTP id q11-v6mr12170930plr.275.1519685099480; Mon, 26 Feb 2018 14:44:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519685099; cv=none; d=google.com; s=arc-20160816; b=MfFUmAtPG73Ydu0Lfzv6kQURquoF9Ad0/uRfQAIb9/ziivCvnDnCQGn94LOmhEjDCW Uc5UFbsR/fuVPn+p54JGDz8VFdN5gwHtJd0kTbOY/4X4MwvXq8L3t/4KWnipCAayv9xn iDwCyw08lA3Cs2N6HCe6B/jUiQnP5DlnDlGqhwY5tIT5ruIfMhPVv4tZtuWuOjO3SX6i U8MuiGGxOMMhIWDgvz8Tja8gju1EJkulRZ6b4yR0CqUhixXaH3z9ZDddmerWTayfnFi8 THGfTrWeKFoMSr4NFYWkvHyUzoAXzGlpEr6UjoJloq34gT1l9/5BRIMHkqq0sdfdkIIc Zl2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=KAkPLzqq06ENHliRCcLtKNDxpjVK7FWlhYOXK7YG5Bk=; b=V1Bmaby9DNgR8BxmXOzrBHYsJ1aEWqScJJ7uU3zdwaLD7ImHTGRkDGDTHB8C4X/EI/ ZuYG3/XrBxJqAjptF7srRbyAZQ/pMz2Zy15MGkN1JAMdR8kU6srrUYUZyfqg4zLFputv qHajd83O9k84HyGA7LOAV9LpaX6EJl10XJwsBeeJWCgyV0kYVVcxi7GDlFkg7ZAe1aHW fhUcQTgZ5cSvYdlNDx0K5Ewma10JzLV+Fqf6QoN5o65B2CfxwTCnj+6dAztu7lbwiyfk l3hZxEdVossLKqas9seSpPgZxTPRRNdqHTEbR2QZwUFbxizg/8hUa049H//FO9MVvkje tCLg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x7-v6si7493041pll.229.2018.02.26.14.44.42; Mon, 26 Feb 2018 14:44:59 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751677AbeBZWnk (ORCPT + 99 others); Mon, 26 Feb 2018 17:43:40 -0500 Received: from mxf98a.netcup.net ([46.38.249.138]:51472 "EHLO mxf98a.netcup.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751630AbeBZWnj (ORCPT ); Mon, 26 Feb 2018 17:43:39 -0500 Received: from [192.168.178.21] (x4d071a18.dyn.telefonica.de [77.7.26.24]) by mxf98a.netcup.net (Postfix) with ESMTPSA id 64FAF140805; Mon, 26 Feb 2018 23:43:38 +0100 (CET) Authentication-Results: mxf98a; spf=pass (sender IP is 77.7.26.24) smtp.mailfrom=rabel@robertabel.eu smtp.helo=[192.168.178.21] Received-SPF: pass (mxf98a: connection is authenticated) Subject: Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands To: Miguel Ojeda Cc: linux-kernel , Willy Tarreau , Geert Uytterhoeven , Andy Shevchenko 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: Robert Abel Message-ID: <50a2fd51-8bdb-d2b7-c2b3-7df638fdedde@robertabel.eu> Date: Mon, 26 Feb 2018 23:43:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20180226224338.10041.88383@mxf98a.netcup.net> X-PPP-Vhost: robertabel.eu Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26 Feb 2018 17:49, Miguel Ojeda wrote: > 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? That's what I felt at first, too. If we can drop the backwards compatibility of repeated xy commands, the whole affair gets much easier, but will unfortunately break existing use. Ex. ^[[Lx004y002x006; --> x6y2, because repeats of x would just overwrite earlier values. That's what the while loop allowed in the first place. I suspect the while loop to parse was just a clever way of parsing y followed by x and x followed by y using the same code and the overwriting behavior is actually an unaccounted-for side-effect. Regards, Robert