All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] proc: Use ppos instead of m->version
Date: Tue, 3 Mar 2020 13:05:59 -0800	[thread overview]
Message-ID: <20200303210559.GV29971@bombadil.infradead.org> (raw)
In-Reply-To: <20200303205303.GA10772@avx2>

On Tue, Mar 03, 2020 at 11:53:03PM +0300, Alexey Dobriyan wrote:
> On Tue, Mar 03, 2020 at 12:29:23PM -0800, Matthew Wilcox wrote:
> > On Tue, Mar 03, 2020 at 10:55:29PM +0300, Alexey Dobriyan wrote:
> > > On Sat, Feb 29, 2020 at 08:59:08AM -0800, Matthew Wilcox wrote:
> > > > -static void *m_next(struct seq_file *m, void *v, loff_t *pos)
> > > > +static void *m_next(struct seq_file *m, void *v, loff_t *ppos)
> > > 
> > > This looks like hungarian notation.
> > 
> > It's the standard naming convention used throughout the VFS.  loff_t is
> > pos, loff_t * is ppos.
> > 
> > $ git grep 'loff_t \*' fs/*.c |wc
> >      77     556    5233
> > $ git grep 'loff_t \*ppos' fs/*.c |wc
> >      43     309    2974
> > $ git grep 'loff_t \*pos' fs/*.c |wc
> >      22     168    1524
> 
> Yes, people copy-pasted terrible thing for years!
> Oh well, whatever...

In an environment where we sometimes pass loff_t and sometimes pass
loff_t *, this convention is a great way to catch copy-and-paste mistakes.
If I have 'pos += done' in a function which takes a loff_t pos, and I
copy-and-paste it to a function which takes a 'loff_t *pos', it's going
to create a bug that hits at runtime.  If that function takes an
loff_t *ppos instead, it'll be a compile-time error, and I'll know to
transform it to *ppos += done;


  reply	other threads:[~2020-03-03 21:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-29 16:59 [PATCH 0/5] Simplify /proc/$pid/maps implementation Matthew Wilcox
2020-02-29 16:59 ` [PATCH 1/5] proc: Inline vma_stop into m_stop Matthew Wilcox
2020-02-29 16:59 ` [PATCH 2/5] proc: remove m_cache_vma Matthew Wilcox
2020-02-29 16:59 ` [PATCH 3/5] proc: Use ppos instead of m->version Matthew Wilcox
2020-03-03 19:55   ` Alexey Dobriyan
2020-03-03 20:29     ` Matthew Wilcox
2020-03-03 20:53       ` Alexey Dobriyan
2020-03-03 21:05         ` Matthew Wilcox [this message]
2020-02-29 16:59 ` [PATCH 4/5] seq_file: Remove m->version Matthew Wilcox
2020-02-29 16:59 ` [PATCH 5/5] proc: Inline m_next_vma into m_next Matthew Wilcox
2020-03-03  8:34 ` [PATCH 0/5] Simplify /proc/$pid/maps implementation Vlastimil Babka
2020-03-03 19:56 ` Alexey Dobriyan
2020-03-03 20:31   ` Matthew Wilcox
2020-03-17 19:31 [PATCH 1/5] proc: inline vma_stop into m_stop Alexey Dobriyan
2020-03-17 19:31 ` [PATCH 3/5] proc: use ppos instead of m->version Alexey Dobriyan

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=20200303210559.GV29971@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=adobriyan@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.