From: Trond Myklebust <trondmy@hammerspace.com>
To: "bfields@fieldses.org" <bfields@fieldses.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuba@kernel.org" <kuba@kernel.org>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
"trix@redhat.com" <trix@redhat.com>,
"chuck.lever@oracle.com" <chuck.lever@oracle.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] NFS: remove trailing semicolon in macro definition
Date: Sun, 29 Nov 2020 16:50:50 +0000 [thread overview]
Message-ID: <110444322a9c301c520c1e57e9a6f02b29ad25c1.camel@hammerspace.com> (raw)
In-Reply-To: <96657eff83195fba1762cb046b3f15d337e5daad.camel@hammerspace.com>
On Sun, 2020-11-29 at 16:42 +0000, Trond Myklebust wrote:
> Hi Tom,
>
> On Fri, 2020-11-27 at 11:43 -0800, trix@redhat.com wrote:
> > From: Tom Rix <trix@redhat.com>
> >
> > The macro use will already have a semicolon.
> >
> > Signed-off-by: Tom Rix <trix@redhat.com>
> > ---
> > net/sunrpc/auth_gss/gss_generic_token.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/sunrpc/auth_gss/gss_generic_token.c
> > b/net/sunrpc/auth_gss/gss_generic_token.c
> > index fe97f3106536..9ae22d797390 100644
> > --- a/net/sunrpc/auth_gss/gss_generic_token.c
> > +++ b/net/sunrpc/auth_gss/gss_generic_token.c
> > @@ -46,7 +46,7 @@
> > /* TWRITE_STR from gssapiP_generic.h */
> > #define TWRITE_STR(ptr, str, len) \
> > memcpy((ptr), (char *) (str), (len)); \
> > - (ptr) += (len);
> > + (ptr) += (len)
> >
> > /* XXXX this code currently makes the assumption that a mech oid
> > will
> > never be longer than 127 bytes. This assumption is not
> > inherent
> > in
>
> There is exactly 1 use of this macro in the code AFAICS. Can we
> please
> just get rid of it, and make the code trivially easier to read?
>
BTW: To illustrate just how obfuscating this kind of macro can be, note
that the line you are changing above will be completely optimised away
in the 1 use case we're talking about. It is bumping a pointer value
that immediately gets discarded.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2020-11-29 16:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 19:43 [PATCH] NFS: remove trailing semicolon in macro definition trix
2020-11-29 16:42 ` Trond Myklebust
2020-11-29 16:50 ` Trond Myklebust [this message]
2020-11-29 17:07 ` Tom Rix
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=110444322a9c301c520c1e57e9a6f02b29ad25c1.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=trix@redhat.com \
/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.