From owner-svn-src-head@freebsd.org Sat Mar 11 02:16:10 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16668D04719; Sat, 11 Mar 2017 02:16:10 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB9171DA9; Sat, 11 Mar 2017 02:16:09 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-ot0-x22a.google.com with SMTP id i1so87394661ota.3; Fri, 10 Mar 2017 18:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c1qerurgbHiqDenL3hTYeu0xlE1t0j57RCdihjveE0w=; b=I65WORqldJOXa87LotDKWbZeKum8vZpZ3YtpaXBsauzKZhngI52zs4KlE60uK4LExP kPlVf/6PlSTUlTN4vt7tclkD8INKPIJOQM862Njl9wvqbXa5Kw1h0bRLpLgRDAChxxt0 wbnzzfo2wLSUjOpm+7OpVAbuA2CrEEEa8qYKKDsGg9aUy3Kbexbx+LGhoI0tzFR6uQun fphVWAkB4eWJlKNB7rlOv98IOzJIbnIddGKg5FHHu81PHvGGWm2HyhwGquvOGgULQtz3 O2jkpNqasbBQvQM71gHNUc+jm9VJNjfVNsukmY7hBNCpf/JhOp8K6/gIBvFkuF3hoJBB vtPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=c1qerurgbHiqDenL3hTYeu0xlE1t0j57RCdihjveE0w=; b=TtNBR6xL0/DFsgZaxBwogoau/QWSv7JI04JFFMIt6v+O/fBobOWSWBT0MXhwy8Kl/4 J6n5mzX9NMQ0qG3VpRIZs8Xm/UpqBea/8RgKywwsEHnbkogZo7R8NiA2skAHItVcNqUr IhKwHBkkbuVydY5UHo2v+3Hb310P4cjCz/xm0HBC2lTjuM0rWgHk7hJobvLPV/C+UIFM yoCnqtG0oueAdAMXK2bZOZx9A/8VrqqMsxFJWOVp/1BGpB5AHpGoLvP/4SkvxlAxnZkl 5g3tSmXKGEAQjPbgOgYvHbWJwZqJypPk+bmxxvZjlfeYKc1th1i/FORgOlxtF5AIpjFX 9kcg== X-Gm-Message-State: AFeK/H1DB451o4WuE2BEBBp32VdnXw4RRxdsgV329Us6piKaTRG1ba1qt0eJ4MxdHL1w5VFuFpwwabp/zV77NA== X-Received: by 10.157.59.230 with SMTP id k93mr12911760otc.9.1489198569068; Fri, 10 Mar 2017 18:16:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.34.229 with HTTP; Fri, 10 Mar 2017 18:16:08 -0800 (PST) Received: by 10.157.34.229 with HTTP; Fri, 10 Mar 2017 18:16:08 -0800 (PST) Reply-To: araujo@freebsd.org In-Reply-To: <20170311120737.R1001@besplex.bde.org> References: <201703100449.v2A4neTK046456@repo.freebsd.org> <20170310181404.C1416@besplex.bde.org> <0906af1d-09aa-fd1e-35cc-9361a68fc160@FreeBSD.org> <20170311120737.R1001@besplex.bde.org> From: Marcelo Araujo Date: Sat, 11 Mar 2017 10:16:08 +0800 Message-ID: Subject: Re: svn commit: r314989 - head/usr.bin/vmstat To: Bruce Evans Cc: Pedro Giffuni , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ngie Cooper , Marcelo Araujo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 02:16:10 -0000 So, in my understanding, bring that cast back might mitigate a bit and make the situation less worst. Am I right? Br, On Mar 11, 2017 10:29 AM, "Bruce Evans" wrote: > On Fri, 10 Mar 2017, Ngie Cooper wrote: > > On Mar 10, 2017, at 03:59, Pedro Giffuni 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. >>> >> > That would be much worse than the cast. The cast is at least in the > right place -- it unpoisons nitimems. "Unsigning" c would poison C. > > Yeah. This might introduce a domino effect though of changes. >> > > Domino effect = fast poisoning. The dominos collapse immediately, but > poisoning takes a long time to spread. In K&R-1 size_t didn't even > exist and the type of sizeof() was unspecified. size_t was born with > unsign poisoning a little later. That is almost 40 years ago, but its > poisoning hasn't spread to many loop variables yet. Full poisoning would > spread it to the closure of all uses of the loop variables, or better > stopped at the source of the poisoning. In the above, the variable is > not used outside of the loop, so the closure is small and easy to see. > > Bruce >