Date: Tue, 27 Oct 2020 14:52:38 -0400 From: Ed Maste <emaste@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Hans Petter Selasky <hselasky@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r366993 - head/sys/net Message-ID: <CAPyFy2D3y4F=e=qaPWCZZCjBUyMzF-Pb%2BZE-OtLEsrUR8cPmKA@mail.gmail.com> In-Reply-To: <20201024104628.GB2643@kib.kiev.ua> References: <202010241023.09OANMcL075640@repo.freebsd.org> <20201024104628.GB2643@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Oct 2020 at 06:46, Konstantin Belousov <kostikbel@gmail.com> wrote:
>
> > -#include <sys/systm.h>
> sys/systm.h should come right after sys/param.h. These two headers are
> exceptions to the normal alphabetical rule.
style(9) claims that sys/types.h and sys/param.h are the special headers:
Kernel include files (sys/*.h) come first. If <sys/cdefs.h> is needed
for __FBSDID(), include it first. If either <sys/types.h> or
<sys/param.h> is needed, include it before other include files.
(<sys/param.h> includes <sys/types.h>; do not include both.) The
remaining kernel headers should be sorted alphabetically.
We should add sys/systm.h to style(9) as another special case if necessary.
> > -infiniband_ipv4_multicast_map(uint32_t addr,
> > - const uint8_t *broadcast, uint8_t *buf)
> > +infiniband_ipv4_multicast_map(
> > + uint32_t addr, const uint8_t *broadcast, uint8_t *buf)
> And this is arguably regression, we fill line up to columns 72-80 before
> splitting to the continuation line.
I agree with kib and arichardson has a clang-format fix for this in
D26978. That said I can see an argument for it being easier to read
with all function args on the same line.
> > - m = NULL; /* mbuf is consumed by resolver */
> > + m = NULL; /* mbuf is consumed by resolver */
> This is a regression as well, in-line comment is typically preceeded by tab.
I suspect this is hard to do in an automated fashion in a way that's
sensible overall (i.e., lining up inline comments on different lines).
This could be a case where we decide to just accept it when someone
uses clang-format on new code, and just discourage sweeping
clang-format changes on existing code.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2D3y4F=e=qaPWCZZCjBUyMzF-Pb%2BZE-OtLEsrUR8cPmKA>