git: e657f3de6dc2 - main - linuxkpi: Remove unneeded {} in atomic_dec_and_lock_irqsave()

Kevin Bowling kevin.bowling at kev009.com
Tue Apr 27 07:47:43 UTC 2021


On Tue, Apr 27, 2021 at 12:01 AM Gary Jennejohn <gljennjohn at gmail.com>
wrote:

> On Mon, 26 Apr 2021 17:16:01 -0700
> Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
> > Yup, I don't want to fatigue Neel or the tree with unnecessary churn,
> > he had the parens, someone said something about brackets {} and he
> > removed the parens.  Since the function needs a rework per mjg's
> > review, it could be done when that occurs.
> >
>
> I'd say that the misunderstanding was caused by the use of the word
> brackets in the comment.
>
> Looking up bracket on wiktionary gives this definitiotn:
>
> 5.  Any of the characters "(", ")", "[", "]", "{", "}", "<" and ">",
> used in pairs to enclose parenthetic remarks, sections of mathematical
> expressions, etc.
>
>     (Britain) "(" and ")" specifically, the other forms above
>     requiring adjectives for disambiguation.
>
>     (US) "[" and "]" specifically - as opposed to the other forms,
>     which have their own technical names.
>
> So, if Neel is used to BE he would remove the parens, which he did.  I,
> as an American, would have been looking for [] and been confused by not
> finding any.
>

Thanks for the explanation.


> So, in future it might be best to explicitly use e.g. {}, [], () in such
> comments.
>

Seems reasonable and effective.  The man page uses precise language and has
the symbols.


> > On Mon, Apr 26, 2021 at 3:29 PM Rick Macklem <rmacklem at uoguelph.ca>
> wrote:
> > >
> > > Neel wrote:
> > > >On 2021-04-26 09:47, Kevin Bowling wrote:
> > > >> I'm not sure all the context or conversation here but the convention
> > > >> is to not use bare return values, i.e in style(9) "Values in return
> > > >> statements should be enclosed in parentheses." and that's what was
> > > >> asked to be changed on this mailing list.
> > > Just fyi to everyone, there is this in style(9):
> > >      In general code can be considered ___new code___ when it makes up
> about 50%
> > >      or more of the file(s) involved.  This is enough to break
> precedents in
> > >      the existing code and use the current style guidelines.
> > >
> > > As such, if the "return 0;" predates this patch series, Neel is correct
> > > to use "return 1;", since that precedent has already been established.
> > > I'll admit I see the above ignored a lot and personally don't care if
> > > the above generality is followed, but it is in style(9) and I do
> > > think a consistent style is preferred over a jumble within a source
> file.
> > >
> > > rick
> > >
> > > The review: https://reviews.freebsd.org/D29988
> > >
> > > I believe I was asked to do this in the review.
> > >
> > > -Neel
> > > >
> > > > Can you use and link to Phabricator for your src commits?  As much as
> > > > possible it is preferable to get it right in one go, for MFCs,
> > > > bisection, etc and this kind of churn should be preventable with
> quick
> > > > reviews.  Feel free to tag me as a reviewer.
> > >
> > > Sure, will do next time.
> > >
> > >
> > > > Regards,
> > > > Kevin
> > >
> > > -Neel
> > >
> > _______________________________________________
> > dev-commits-src-all at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
> > To unsubscribe, send any mail to "
> dev-commits-src-all-unsubscribe at freebsd.org"
>
>
> --
> Gary Jennejohn
>


More information about the dev-commits-src-all mailing list