[lkml]   [2019]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: rfc: treewide scripted patch mechanism? (was: Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang)QUILT
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.


 \ /
  Last update: 2019-08-21 01:29    [W:0.087 / U:3.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site