svn commit: r303600 - head/usr.bin/indent

[Piotr Stefaniak]

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 
the opinion that the memset()-based equivalent of bzero() has fewer 
portability consequences, which is worth paying attention to. Please 
consider the fact that NetBSD has done this replacement.

I do agree that replacing the expression with the type name was a 
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 
style(9). I have changed both my own code submitted for review and the 
rest of style violations of this kind as a separate patch 
(https://github.com/pstef/freebsd_indent/commit/a2befd74fa54c91d96a38317e90d38ef17682f4b). 
I had expected the style fixes to get committed before the change in 
r303600, in belief that doing so would render possible complaints as the 
one quoted above as not relevant anymore.

> Regressions started in r93440 with sizeof(object) in an nitems() expansion.
> 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 
indent(1)'s code to make it more style(9)-compliant (not least because 
it's tempting to imagine indent(1) being able to re-indent itself in 
accordance with style(9) at some point) but right now I'm confused as to 
what style decisions in the patches I submit are expected of me.