Re: [PATCH v6] can, tty: can327 CAN/ldisc driver for ELM327 based OBD-II adapters

From: Max Staudt <max@enpas.org>
To: Vincent Mailhol <vincent.mailhol@gmail.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	linux-can@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Oliver Neukum <oneukum@suse.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6] can, tty: can327 CAN/ldisc driver for ELM327 based OBD-II adapters
Date: Sat, 14 May 2022 13:11:40 +0200	[thread overview]
Message-ID: <20220514131128.5e647fb8.max@enpas.org> (raw)
In-Reply-To: <CAMZ6RqLj2eLX2UWMvGc9rH2SP6HNuqBAXnwJ6q6qvk+7QWE8pA@mail.gmail.com>

On Sat, 14 May 2022 12:14:24 +0900
Vincent Mailhol <vincent.mailhol@gmail.com> wrote:

> But I still think it is possible to do pointer arithmetic.
> 
> len = strnchr(elm->rxbuf, elm->rxfill, '\r') - elm->rxbuf;
> (I let you check that I did not do an off by one mistake).
> 
> The above should also work with memchr(). Although the C standard
> doesn't allow pointer arithmetic on void *, GNU C adds an extension
> for that: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
> 
> As I said before, your for loop is not fundamentally wrong, this is
> just not my prefered approach. You have my suggestion, choose what you
> prefer.

Yeah, this is the arithmetic that I'd like to avoid here. In my
opinion, it is clearer with indices.

If I were searching through a UTF-8 string (i.e. with variable width
chars), that'd be another matter entirely IMHO, and I'd rely on C
library functions that know more about UTF that I do. But it's really
just naked ASCII bytes this time.

...unless memchr() may be faster than the loop? Could this happen?

Max