LKML Archive on
 help / color / Atom feed
From: Linus Torvalds <>
To: Joe Perches <>
Cc: Stephen Rothwell <>,
	Julia Lawall <>,
	"Gustavo A. R. Silva" <>,
	LKML <>,,
	Linux Next Mailing List <>
Subject: Re: rfc: treewide scripted patch mechanism? (was: Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang)QUILT
Date: Tue, 20 Aug 2019 16:28:35 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Aug 19, 2019 at 5:08 PM Joe Perches <> wrote:
> 2: would be Julia Lawall's stracpy change done
> with coccinelle: (attached)

I'm not actually convinced about stracpy() and friends.

It seems to be yet another badly thought out string interface, and
there are now so many of them that no human being can keep track of

The "badly thought out" part is that it (like the original strlcpy
garbage from BSD) thinks that there is only one size that matters -
the destination.

Yes, we fixed part of the "source is also limited" with strscpy(). It
didn't fix the problem with different size limits, but at least it
fixed the fundamentally broken assumption that the source has no size
limit at all.

Honestly, I really really REALLY don't want yet another broken string
handling function, when we still have a lot of the old strlcpy() stuff
in the tree from previous broken garbage.

The fact is, when you copy strings, both the destination *AND* the
source may have size limits. They may be the same. Or they may not be.

This is particularly noticeable in the "str*_pad()" versions. It's
simply absolutely and purely wrong. I will note that we currently have
not a single user or strscpy_pad() in the whole kernel outside of the
testing code.

And yes, we actually *do* have real and present cases of "source and
destination have different sizes". They aren't common, but they do

So I'm putting my foot down on yet another broken string copy
interface from people who do not understand this fundamental issue.


  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-05 22:11 [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang Joe Perches
2019-08-05 22:23 ` Nathan Chancellor
2019-08-10 19:32 ` Joe Perches
2019-08-10 19:44   ` Linus Torvalds
2019-08-10 20:18     ` Joe Perches
2019-08-10 20:33       ` Joe Perches
2019-08-16 19:58         ` rfc: treewide scripted patch mechanism? (was: Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang) Joe Perches
2019-08-19 23:24           ` rfc: treewide scripted patch mechanism? (was: Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang)QUILT Stephen Rothwell
2019-08-20  0:08             ` Joe Perches
2019-08-20 23:28               ` Linus Torvalds [this message]
2019-08-20 23:37                 ` Joe Perches
2019-08-21  0:39                   ` Linus Torvalds
2019-08-26  8:58                     ` Geert Uytterhoeven
2019-08-21  0:20                 ` Joe Perches
2019-08-21  0:43                   ` Linus Torvalds
2019-08-21  0:58                     ` stracpy Joe Perches
2019-08-21  4:01                     ` rfc: treewide scripted patch mechanism? (was: Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang)QUILT Willy Tarreau
2019-08-21  0:33               ` Stephen Rothwell
2019-08-11  2:04       ` [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang Nathan Chancellor
2019-08-11  3:06         ` Joe Perches
2019-08-11  3:17           ` Nathan Chancellor
2019-08-11  3:54             ` Joe Perches
2019-08-12  5:07               ` Joe Perches
2019-08-11  6:50             ` Bernd Petrovitsch
2019-08-12 16:28           ` Nick Desaulniers
2019-08-12 17:42             ` Joe Perches
2019-08-13 12:44             ` Miguel Ojeda
2019-08-15  2:44               ` Joe Perches
2019-08-16  8:47                 ` Joe Perches

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git
	git clone --mirror lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone