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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220514131128.5e647fb8.max@enpas.org>
Date:   Sat, 14 May 2022 13:11:40 +0200
From:   Max Staudt <max@...as.org>
To:     Vincent Mailhol <vincent.mailhol@...il.com>
Cc:     Wolfgang Grandegger <wg@...ndegger.com>,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        linux-can@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Oliver Neukum <oneukum@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6] can, tty: can327 CAN/ldisc driver for ELM327 based
 OBD-II adapters

On Sat, 14 May 2022 12:14:24 +0900
Vincent Mailhol <vincent.mailhol@...il.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