svn commit: r314989 - head/usr.bin/vmstat

Ngie Cooper yaneurabeya at gmail.com
Fri Mar 10 19:19:36 UTC 2017


> On Mar 10, 2017, at 03:59, Pedro Giffuni <pfg at FreeBSD.org> wrote:
> 
>> On 3/10/2017 2:45 AM, Bruce Evans wrote:
>>> On Fri, 10 Mar 2017, Marcelo Araujo wrote:
>>> 
>>> ...
>>> Log:
>>> Use nitems() from sys/param.h and also remove the cast.
>>> 
>>> Reviewed by:    markj
>>> MFC after:    3 weeks.
>>> Differential Revision:    https://reviews.freebsd.org/D9937
>>> ...
>>> Modified: head/usr.bin/vmstat/vmstat.c
>>> ============================================================================== 
>>> --- head/usr.bin/vmstat/vmstat.c    Fri Mar 10 04:30:31 2017 (r314988)
>>> +++ head/usr.bin/vmstat/vmstat.c    Fri Mar 10 04:49:40 2017 (r314989)
>>> @@ -288,17 +288,13 @@ retry_nlist:
>>>                namelist[X_SUM].n_name = "_cnt";
>>>                goto retry_nlist;
>>>            }
>>> -            for (c = 0;
>>> -                 c < (int)(sizeof(namelist)/sizeof(namelist[0]));
>>> -                 c++)
>>> +            for (c = 0; c < nitems(namelist); c++)
>>>                if (namelist[c].n_type == 0)
>>>                    bufsize += strlen(namelist[c].n_name) + 1;
>> 
>> This undoes fixes to compile at WARNS=2 in r87690 and now breaks at WARNS=3.
>> vmstat is still compiled at WARNS=1.
>> 
>> nitems suffers from the same unsigned poisoning as the sizeof() expression
>> (since it reduces to the same expression.  Casting to int in the expression
>> to fix the warning would break exotic cases.  Of course, nitems is
>> undocumented so no one knows when it is supposed to work).
>> 
>> vmstat compiles with no errors at WARNS=2.  At WARNS=3, it used to compile
>> with 9 excessive warnings (about the good style of omitting redundant
>> initializers).  Now it compiles with 10 excessive warnings.  1 more about
>> comparison between signed unsigned.  This warning is a compiler bug.  Both
>> gcc-4.2.1 and clang-3.9.0 have it.  It is enabled by -W, which is put in
>> CFLAGS at WARNS >= 3, or by -Wsign-compare.
>> 
>> These compilers even complain about:
>> 
>>    int c;
>> 
>>    for (c = 0; c < 1U; c++)
>>        foo();
>> 
>> where it is extremely clear that c never gets converted to a wrong value
>> when it is promoted to unsigned for the comparison.  Compilers should
>> only warn about sign mismatches if they can't figure out the ranges or
>> if they can figure out the ranges but dangerous promotiions occur.
>> Compilers do excessive unrolling and other optimizations of loops like
>> the above, and they must figure out the ranges for this.
>> 
> 
> I haven't looked at the code but it would seem like you can unsign c and avoid the cast.

Yeah. This might introduce a domino effect though of changes.
Cheers!
-Ngie


More information about the svn-src-head mailing list