From: Joe Perches <joe@perches.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: apw@canonical.com, Christoph Lameter <cl@linux.com>,
Daniel Micay <danielmicay@gmail.com>,
Dennis Zhou <dennis@kernel.org>,
dwaipayanray1@gmail.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Kees Cook <keescook@chromium.org>, Linux-MM <linux-mm@kvack.org>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
mm-commits@vger.kernel.org, Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Miguel Ojeda <ojeda@kernel.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>, Tejun Heo <tj@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [patch 9/9] mm/vmalloc: add __alloc_size attributes for better bounds checking
Date: Fri, 10 Sep 2021 22:29:23 -0700 [thread overview]
Message-ID: <4028a9be304ae79d55d2ad099651c640f583df5d.camel@perches.com> (raw)
In-Reply-To: <CAHk-=wgfbSyW6QYd5rmhSHRoOQ=ZvV+jLn1U8U4nBDgBuaOAjQ@mail.gmail.com>
On Fri, 2021-09-10 at 10:23 -0700, Linus Torvalds wrote:
> On Thu, Sep 9, 2021 at 8:10 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > +__alloc_size(1)
> > extern void *vmalloc(unsigned long size);
[]
> So wouldn't this all have looked much more natural as
>
> void *vmalloc(unsigned long size) __malloc(1);
>
> instead? Hmm?
I think not as the __malloc attribute and in fact all the other function
attributes are effectively uninteresting when it comes to grepping for
function declarations.
Putting the attribute lists after the function arguments in many
cases would just be visual noise.
My preference would be for declarations to be mostly like:
[optional attribute list[
<return type> function(arguments);
Frequently there are multiline function declarations with many
arguments similar to either of
[optional attribute list]
<return type> function(type arg1,
type arg2,
etc...);
or
[optional attribute list]
<return type>
function(type arg1,
type arg2,
etc...);
which always makes grep rather difficult.
And given the expansion is naming lengths there are more and more
of these multiline argument lists. It doesn't matter if the line
length is increased above 80 columns or not.
next prev parent reply other threads:[~2021-09-11 5:36 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 3:09 incoming Andrew Morton
2021-09-10 3:10 ` [patch 1/9] mm: move kvmalloc-related functions to slab.h Andrew Morton
2021-09-10 3:10 ` [patch 2/9] rapidio: avoid bogus __alloc_size warning Andrew Morton
2021-09-10 3:10 ` [patch 3/9] Compiler Attributes: add __alloc_size() for better bounds checking Andrew Morton
2021-09-10 3:10 ` [patch 4/9] checkpatch: add __alloc_size() to known $Attribute Andrew Morton
2021-09-10 3:10 ` [patch 5/9] slab: clean up function declarations Andrew Morton
2021-09-10 3:10 ` [patch 6/9] slab: add __alloc_size attributes for better bounds checking Andrew Morton
2021-09-10 3:10 ` [patch 7/9] mm/page_alloc: " Andrew Morton
2021-09-10 3:10 ` [patch 8/9] percpu: " Andrew Morton
2021-09-10 3:10 ` [patch 9/9] mm/vmalloc: " Andrew Morton
2021-09-10 17:23 ` Linus Torvalds
2021-09-10 18:43 ` Kees Cook
2021-09-10 19:17 ` Linus Torvalds
2021-09-10 19:32 ` Kees Cook
2021-09-10 19:49 ` Nick Desaulniers
2021-09-10 20:16 ` Linus Torvalds
2021-09-10 20:47 ` Kees Cook
2021-09-10 20:58 ` Nick Desaulniers
2021-09-10 21:07 ` Kees Cook
2021-09-11 5:29 ` Joe Perches [this message]
2021-09-21 23:37 ` Kees Cook
2021-09-21 23:45 ` Joe Perches
2021-09-22 2:25 ` function prototype element ordering Kees Cook
2021-09-22 4:24 ` Joe Perches
2021-09-24 19:43 ` Kees Cook
2021-09-22 7:24 ` Alexey Dobriyan
2021-09-22 8:51 ` Joe Perches
2021-09-22 10:45 ` Alexey Dobriyan
2021-09-22 11:19 ` Jani Nikula
2021-09-22 21:15 ` Linus Torvalds
2021-09-23 5:10 ` Joe Perches
2021-09-25 19:40 ` David Laight
2021-09-26 21:03 ` Linus Torvalds
2021-09-27 8:21 ` David Laight
2021-09-27 9:22 ` Willy Tarreau
2021-09-10 17:11 ` incoming Kees Cook
2021-09-10 20:13 ` incoming Kees Cook
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=4028a9be304ae79d55d2ad099651c640f583df5d.camel@perches.com \
--to=joe@perches.com \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=cl@linux.com \
--cc=danielmicay@gmail.com \
--cc=dennis@kernel.org \
--cc=dwaipayanray1@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mm-commits@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/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).