On Tue, Oct 27, 2020 at 2:23 PM Konstantin Belousov <kostik...@gmail.com> wrote:
> On Tue, Oct 27, 2020 at 02:52:38PM -0400, Ed Maste wrote: > > 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. > Yes sys/systm.h is very special because it defines a lot of basic things, > like asserts, printf(9), and so on, and because it includes enough other > popular headers. Its intent is to gather all common stuff, which makes > it both convenient and necessary to go before other (but sys/param.h is > more > prioritized). > So sorted after sys/types.h or sys/param.h should be documented in style(9). https://reviews.freebsd.org/D26981 has a proposed change. Warner > > > > > > -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-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
