From: Oscar Carter <oscar.carter@gmx.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
Quentin Deslandes <quentin.deslandes@itdev.co.uk>
Cc: Oscar Carter <oscar.carter@gmx.com>,
Forest Bond <forest@alittletooquiet.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Malcolm Priestley <tvboxspy@gmail.com>,
Colin Ian King <colin.king@canonical.com>,
Gabriela Bittencourt <gabrielabittencourt00@gmail.com>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: vt6656: Use ARRAY_SIZE instead of hardcoded size
Date: Thu, 26 Mar 2020 18:22:25 +0100 [thread overview]
Message-ID: <20200326172224.GC3629@ubuntu> (raw)
In-Reply-To: <20200325091924.GB15158@jiffies>
On Wed, Mar 25, 2020 at 09:19:24AM +0000, Quentin Deslandes wrote:
> On 03/24/20 16:18:30, Dan Carpenter wrote:
> > That's a bit over engineering something which is pretty trivial.
> > Normally, we would just make the size a define instead of a magic number
> > 14.
>
> My bad, I meant "define", not "macro".
>
> > If people change the size in the future (unlikely) and it causes a bug
> > then they kind of deserve it because they need to ensure all the new
> > stuff is initialized, right? If they change it and it results in a
> > buffer overflow then static checkers would complain. If they changed it
> > and it resulted in uninitialized data being used then it would be zero
> > so that's okay.
>
> I wasn't sure where I should stand on this, that's clearer now.
>
> Thanks,
> Quentin
Dan and Quentin, thanks for your time to review my work, and make comments.
oscar carter
prev parent reply other threads:[~2020-03-26 17:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 17:40 [PATCH v2] staging: vt6656: Use ARRAY_SIZE instead of hardcoded size Oscar Carter
2020-03-24 9:54 ` Quentin Deslandes
2020-03-24 13:18 ` Dan Carpenter
2020-03-25 9:19 ` Quentin Deslandes
2020-03-26 17:22 ` Oscar Carter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200326172224.GC3629@ubuntu \
--to=oscar.carter@gmx.com \
--cc=colin.king@canonical.com \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=forest@alittletooquiet.net \
--cc=gabrielabittencourt00@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quentin.deslandes@itdev.co.uk \
--cc=tvboxspy@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox