kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Stephen Kitt <steve@sk2.org>, Kees Cook <keescook@chromium.org>,
	Nitin Gote <nitin.r.gote@intel.com>,
	jannh@google.com, kernel-hardening@lists.openwall.com,
	 linux-kernel@vger.kernel.org,
	Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Subject: Re: [PATCH] checkpatch: Added warnings in favor of strscpy().
Date: Wed, 24 Jul 2019 04:41:07 -0700	[thread overview]
Message-ID: <9bb45dcae38b0f9322c0ce033c041ede02f8d7ec.camel@perches.com> (raw)
In-Reply-To: <20190722162804.754943bc@lwn.net>

On Mon, 2019-07-22 at 16:28 -0600, Jonathan Corbet wrote:
> On Mon, 22 Jul 2019 15:24:33 -0700
> Joe Perches <joe@perches.com> wrote:
> 
> > > If the functions themselves are fully defined in the .h file, I'd just add
> > > the kerneldoc there as well.  That's how it's usually done, and you want
> > > to keep the documentation and the prototypes together.  
> > 
> > In this case, it's a macro and yes, the kernel-doc could
> > easily be set around the macro in the .h, but my desire
> > is to keep all the string function kernel-doc output
> > together so it should be added to lib/string.c
> > 
> > Are you suggesting I move all the lib/string.c kernel-doc
> > to include/linux/string.h ?
> 
> If you want the *output* together, just put the kernel-doc directives
> together in the RST file that pulls it all in.  Or am I missing something
> here?

The negative of the kernel-doc separation of prototypes by .h
and .c files is that the ordering of the functions in the .rst
outout files doesn't make much logical sense.

stracpy is pretty far away from strscpy in the list of functions.


  parent reply	other threads:[~2019-07-24 11:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 11:55 [PATCH] checkpatch: Added warnings in favor of strscpy() Nitin Gote
2019-06-28 14:46 ` Kees Cook
2019-07-01  8:42   ` Gote, Nitin R
2019-07-02 17:31     ` Kees Cook
2019-06-29 16:15 ` Stephen Kitt
2019-07-02 17:25   ` Kees Cook
2019-07-06 12:42     ` Stephen Kitt
2019-07-07  7:40       ` Stephen Kitt
2019-07-22 17:50       ` Kees Cook
2019-07-22 17:59         ` Joe Perches
2019-07-22 21:01           ` Stephen Kitt
2019-07-22 21:50             ` Joe Perches
2019-07-22 21:57               ` Jonathan Corbet
2019-07-22 22:24                 ` Joe Perches
2019-07-22 22:28                   ` Jonathan Corbet
2019-07-22 22:35                     ` Joe Perches
2019-07-24 11:41                     ` Joe Perches [this message]
2019-07-04  5:54 Nitin Gote
2019-07-04 20:46 ` 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:
  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=9bb45dcae38b0f9322c0ce033c041ede02f8d7ec.camel@perches.com \
    --to=joe@perches.com \
    --cc=corbet@lwn.net \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nitin.r.gote@intel.com \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=steve@sk2.org \
    /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 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).