svn commit: r303586 - head/bin/sh

[Warner Losh]

On Sun, Jul 31, 2016 at 11:51 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Sun, 31 Jul 2016, Warner Losh wrote:
>
>> On Sun, Jul 31, 2016 at 2:16 PM, Jilles Tjoelker <jilles at stack.nl> wrote:
>>>
>>> On Sun, Jul 31, 2016 at 01:43:16PM +0000, Alexey Dokuchaev wrote:
>>>>
>>>> On Sun, Jul 31, 2016 at 01:11:34PM +0000, Jilles Tjoelker wrote:
>>>>>
>>>>> New Revision: 303586
>>>>> URL: https://svnweb.freebsd.org/changeset/base/303586
>>>
>>>
>>>>> Log:
>>>>>   sh: Fix a clang warning.
>>>
>>>
>>>>>   Submitted by:     bdrewery
>>>
>>>
>>>>> Modified:
>>>>>   head/bin/sh/expand.c
>>>
>>>
>>>>> Modified: head/bin/sh/expand.c
>>>>>
>>>>> ==============================================================================
>>>>> --- head/bin/sh/expand.c    Sun Jul 31 12:59:10 2016        (r303585)
>>>>> +++ head/bin/sh/expand.c    Sun Jul 31 13:11:34 2016        (r303586)
>>>>> @@ -473,7 +473,8 @@ expbackq(union node *cmd, int quoted, in
>>>>>             if (--in.nleft < 0) {
>>>>>                     if (in.fd < 0)
>>>>>                             break;
>>>>> -                   while ((i = read(in.fd, buf, sizeof buf)) < 0 &&
>>>>> errno == EINTR);
>>>>> +                   while ((i = read(in.fd, buf, sizeof buf)) < 0 &&
>>>>> errno == EINTR)
>>>>> +                           ;
>>>
>>>
>>>> `continue;' would be even better; some tools might barf at stray
>>>> semicolon.
>>>
>>>
>>> Both continue; and ; (the latter with and without comment) occur in the
>>> source tree many times. I don't really like a continue that does nothing
>>> because it is at the end of a loop, so I prefer to make this whitespace
>>> change only (there are two more instances in bin/sh). I think a sole
>>> semicolon on a line is conspicuous enough that nothing additional is
>>> required.
>>
>>
>> For humans, yes. For picky tools that warn about strange constructs, no.
>> Clang may be happy, but there's many other tools that expect you to
>> declare
>> an 'empty' while loop with continue. This tradition has dated back to
>> at least the
>> late 80's...
>
>
> Buggy tools.  I thought that programmers used the stand-alone semicolon
> since that is shorter and clearer.

It cannot be on the same line though.

> The stand-alone semicolon is bad if it is misformatted.  'while(foo());'
> is shorter and unclearer.  A C parser must ignore whitespace, so you
> need a tool like indent that sort of understands whitespace to disallow
> while(foo()); but accept 'while (foo())\n\t;'.  It is not far from full
> indent(1) and insisting on the correct number of \t's before the semicolon.

A C parser doesn't completely ignore the whitespace if it doesn't warn
in both cases...

Warner