On Sat, 24 Oct 2020 at 06:46, Konstantin Belousov <kostik...@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. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"