Re: git: 6ac7c9f06ae9 - main - daemon: remove redundant parameter from listen_child()

On 12/27/23 09:48, Warner Losh wrote:
> 
> 
> On Wed, Dec 27, 2023 at 8:31 AM Alexey Dokuchaev <danfe@freebsd.org 
> <mailto:danfe@freebsd.org>> wrote:
> 
>     On Wed, Dec 27, 2023 at 04:49:20PM +0200, Konstantin Belousov wrote:
>      > On Wed, Dec 27, 2023 at 06:08:08AM +0000, Kyle Evans wrote:
>      > > commit 6ac7c9f06ae9b7ef070c1f8a57dcc52be4dd45b7
>      > >
>      > >   daemon: remove redundant parameter from listen_child()
>      > >
>      > >   state already contains pipe fd
>      > > ...
>      > > @@ -448,9 +448,7 @@ daemon_eventloop(struct daemon_state *state)
>      > >                                     /* child is dead, read all
>     until EOF */
>      > >                                     state->pid = -1;
>      > >                                     state->mode = MODE_NOCHILD;
>      > > -                                   while
>     (listen_child(state->pipe_fd[0],
>      > > -                                       state))
>      > > -                                           ;
>      > > +                                   while (listen_child(state));
>      >
>      > This line is the style regression.
> 
>     We've seen this before and I reckon these regressions would keep
>     happening
>     when semicolon is put on the new line by itself alone.  This would
>     be less
>     likely to happen and makes the intention more obvious to say
>     ``continue;''.
> 
> 
> fwiw, that was the recommendation of the 'old unix hands' on USENET
> in the mid 80s.  It made the intention clear. I was told, but never 
> encountered,
> that some linting tools will warn about the above style but not while 
> (foo) continue;
> and so that's been my personal style ever since. I've debugged lots of 
> code that
> used this style, and it's a bugger to sort out if the indentation is 
> correct and the ;
> is intended at the end of the line, or if it was intended...
> 
> Warner

Both of these fixed in e064557916a905d0add20c4012cf3678131c11e7, thanks. 
  I also like the more explicit form here.