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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.