LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Len Baker <len.baker@gmx.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	James Morse <james.morse@arm.com>,
	Robert Richter <rric@kernel.org>, Joe Perches <joe@perches.com>,
	David Laight <David.Laight@aculab.com>,
	Kees Cook <keescook@chromium.org>,
	linux-hardening@vger.kernel.org, linux-edac@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] EDAC/mc: Prefer strscpy over strcpy
Date: Fri, 27 Aug 2021 19:54:07 +0200	[thread overview]
Message-ID: <YSkmv8kz2z3OBHVe@zn.tnic> (raw)
In-Reply-To: <20210827173633.GA3040@titan>

On Fri, Aug 27, 2021 at 07:36:33PM +0200, Len Baker wrote:
> Well, the main purpose is to clean up the proliferation of str*cpy functions.
> One task is to remove the strcpy uses: The first step (previous step) would
> be to remove all the strcpy uses. Then, as a second step remove all the
> strcpy implementations.
> 
> I hope that this clarify your question.

Yes, it does.

Now lemme clarify why I'm asking: when your patch is committed to the
kernel tree and someone reads its commit message months or even years
from now - and those who do that are mostly maintainers trying to figure
out why stuff was done the way it was - they will read:

"This is a previous step in the path to remove the strcpy() function
entirely from the kernel."

and wonder what previous step that is what the following step is...

So, long story short, your commit message should be complete on its own
and understandable without any references to things which might not be
as clear and self-evident in the future as they are now.

Makes sense?

Also, if you're wondering if you should send the patch with the error
checking of strscpy() added, as I requested, even if it might look
superfluous now, yes you should.

Even if it looks impossible now, we might change some of those defines
in the future and forget to touch the logic which generates e->label and
we might end up exhausting that string.

So it would be a lot more robust if something would catch that change,
albeit seemingly redundant now.

I sincerely hope that clears up things.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2021-08-27 17:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-14  7:55 Len Baker
2021-08-23 17:30 ` Borislav Petkov
2021-08-24 10:28   ` Len Baker
2021-08-24 18:26     ` Borislav Petkov
2021-08-24 19:05       ` Joe Perches
2021-08-25  8:48       ` David Laight
2021-08-27 17:36       ` Len Baker
2021-08-27 17:54         ` Borislav Petkov [this message]
2021-08-27 19:08           ` Joe Perches
2021-08-29 16:14           ` Len Baker

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=YSkmv8kz2z3OBHVe@zn.tnic \
    --to=bp@alien8.de \
    --cc=David.Laight@aculab.com \
    --cc=james.morse@arm.com \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=len.baker@gmx.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=rric@kernel.org \
    --cc=tony.luck@intel.com \
    --subject='Re: [PATCH v4] EDAC/mc: Prefer strscpy over strcpy' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).