On Tue, 9 Jul 2019 17:54:17 +0530 NitinGote <nitin.r.gote@xxxxxxxxx> wrote: > From: Nitin Gote <nitin.r.gote@xxxxxxxxx> The patch needs a proper subject line. > 1. Deprecate strcpy() in favor of strscpy(). > 2. Deprecate strlcpy() in favor of strscpy(). > 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad(). > > Updated strncpy() section in Documentation/process/deprecated.rst > to cover strscpy_pad() case. > > Signed-off-by: Nitin Gote <nitin.r.gote@xxxxxxxxx> > --- > Change log: > v1->v2 > - For string related apis, created different %deprecated_string_api > and these will get emitted at CHECK Level using command line option > -f/--file to avoid bad patched from novice script users. > > v2->v3 > - Avoided use of $check in implementation. > - Incorporated trivial comments. > > Documentation/process/deprecated.rst | 6 +++--- > scripts/checkpatch.pl | 24 ++++++++++++++++++++++++ > 2 files changed, 27 insertions(+), 3 deletions(-) > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst > index 49e0f64a3427..f564de3caf76 100644 > --- a/Documentation/process/deprecated.rst > +++ b/Documentation/process/deprecated.rst > @@ -93,9 +93,9 @@ will be NUL terminated. This can lead to various linear read overflows > and other misbehavior due to the missing termination. It also NUL-pads the > destination buffer if the source contents are shorter than the destination > buffer size, which may be a needless performance penalty for callers using > -only NUL-terminated strings. The safe replacement is :c:func:`strscpy`. > -(Users of :c:func:`strscpy` still needing NUL-padding will need an > -explicit :c:func:`memset` added.) > +only NUL-terminated strings. In this case, the safe replacement is > +:c:func:`strscpy`. If, however, the destination buffer still needs > +NUL-padding, the safe replacement is :c:func:`strscpy_pad`. Please don't use :c:func: in anything new; just write that as strscpy() (or whatever) and The Right Thing will happen. (Maybe we need a checkpatch rule for that :) Thanks, jon