Date: Mon, 1 Aug 2016 15:24:20 +0000 From: Piotr Stefaniak <email@piotr-stefaniak.me> To: Bruce Evans <brde@optusnet.com.au>, Xin Li <delphij@delphij.net> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "d@delphij.net" <d@delphij.net>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "Pedro F. Giffuni" <pfg@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r303600 - head/usr.bin/indent Message-ID: <VI1PR0901MB1501A3520B82E3DB32EC46E785040@VI1PR0901MB1501.eurprd09.prod.outlook.com> In-Reply-To: <20160801155148.I884@besplex.bde.org> References: <201607312136.u6VLaeRb058693@repo.freebsd.org> <8d6114b7-cd71-239a-dcc4-03a6d568482c@delphij.net> <20160801155148.I884@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-08-01 08:08, Bruce Evans wrote: > On Sun, 31 Jul 2016, Xin Li wrote: > >> On 7/31/16 14:36, Pedro F. Giffuni wrote: >>> - bzero(f, sizeof *f); >>> + memset(f, 0, sizeof(struct fstate)); >> ^^^^^^^^^^^^^^^^^^^^^ This is much more error-prone >> than sizeof(*f) IMHO. > > I also prefer bzero(). I hope this is merely a preference and not a hard rule, because I'm of=20 the opinion that the memset()-based equivalent of bzero() has fewer=20 portability consequences, which is worth paying attention to. Please=20 consider the fact that NetBSD has done this replacement. I do agree that replacing the expression with the type name was a=20 regression; it was my mistake. > Removal of the space after sizeof is another regression. KNF disallows > the space, but indent's style is very far from KNF. It isn't clear if > indent's style is to require the space, since old versions of indent > never used sizeof(typename), and 'sizeof object' requires the space. I was specifically asked in the D6966 differential review to adhere to=20 style(9). I have changed both my own code submitted for review and the=20 rest of style violations of this kind as a separate patch=20 (https://github.com/pstef/freebsd_indent/commit/a2befd74fa54c91d96a38317e90= d38ef17682f4b).=20 I had expected the style fixes to get committed before the change in=20 r303600, in belief that doing so would render possible complaints as the=20 one quoted above as not relevant anymore. > Regressions started in r93440 with sizeof(object) in an nitems() expansio= n. > The style of this is very different from an nitems() expansion in r1590. > There was 1 more sizeof(object) and 1 sizeof(int). This is the first > sizeof(typename) where 'sizeof object' cannot be used for technical > reasons. > > KNF also requires parentheses for sizeof(object). Then the space is > unnecessary and disallowed. On a more general note, I imagined we're heading towards slowly changing=20 indent(1)'s code to make it more style(9)-compliant (not least because=20 it's tempting to imagine indent(1) being able to re-indent itself in=20 accordance with style(9) at some point) but right now I'm confused as to=20 what style decisions in the patches I submit are expected of me.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?VI1PR0901MB1501A3520B82E3DB32EC46E785040>