linux-kernel - Re: [PATCH v1 4/4] auxdisplay: lcd2s: Use array size explicitly in lcd2s

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]

Date:   Wed, 23 Mar 2022 20:15:57 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 4/4] auxdisplay: lcd2s: Use array size explicitly in lcd2s_gotoxy()

Hi Andy,

On Sat, Mar 19, 2022 at 12:37 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
>
> With [] and parameters not being bytes by type one needs an additional
> processing step to figure that out. When I see u8 ...[3] I immediately
> understand that there are 3 _bytes_. Moreover, [] is error prone when
> one may add something to the buffer with the expectation that it will
> work somehow (for example, with an old device you need 3, with new
> device revision you need 4 bytes and passing 4 bytes breaks the old
> device). Of course most of that quite likely won't happen.

I agree it is better to be explicit -- I just found the commit message
very confusing, i.e. the type will always be `u8`, what is unclear is
the total length, not so much the type change.

I think the best approach when one needs an array to stay a particular
size due to some external constraint (like hardware) would be to use a
`static_assert` with a comment mentioning where the requirement comes
from. Or at least a comment above the array.

Either way, I applied this one too to -next a few days ago. Thanks!

Cheers,
Miguel