From owner-svn-src-all@freebsd.org Sat Feb 20 03:43:50 2016 Return-Path: Delivered-To: svn-src-all@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 1C26FAAEE66; Sat, 20 Feb 2016 03:43:50 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 A5F9F1277; Sat, 20 Feb 2016 03:43:49 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id g62so102152779wme.1; Fri, 19 Feb 2016 19:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5aAU9f5d41ZYmRYl4SMzUKFcVhmHWQ/m4+/1iusp8qE=; b=MlDqvYX+ffkd/l5UuB55mbrWmPLkr8wc4TU/cotcArVMzHialO/1T7F4HXjW8wzV4T kIVXU2hlTQfqqz54Jow8ywqOdIS+2+dt61FoV5qzaKeCdVTD7A9PsKh19Se2iuqNEQd/ 8Z+ZWZ30A2kJA38vUWUfIXXAj4kWhAi91O5xCmtX5IF7qPmxMA1K5XPVKmlisHxWMGKz AtyOT3QntIa0hnF98hgLe08ojXxyIVt62ETJUx7iX/Ue8nk4aH6NHkipH39pw2bhZvQ4 eTYym+MhI92n0OAlZfNnhn1gmebKfC75ZQzVw/SwHBpKm8ZLvuGKv9C4h1vjbcQcM+CF t+cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5aAU9f5d41ZYmRYl4SMzUKFcVhmHWQ/m4+/1iusp8qE=; b=DNQg3I7txnoOkZO8/TSiogIy9GkWWzmIc34LPr5/dbmJDpFRjzvS9smASNwEAIfi1K 2I8VHvF6PraLSvtffcSV5j3tOU1Xa/18vITUzbf42rAYXPtYpF3w8ZjgX152YmDQDvC3 FTbkIZ+F7ylYtkvjzI4TPHeKUZv4b3dcgE+CEvbzKph4JCBlz2R6SG1YXvWiruwK/WnD vcr8A4TnakmyjhgWazNJK7ar8Sb2YdlOHlb0ninUaNl7ufDpnQOTrsPkGADvDxkhClg6 lhehTkjfM09HAoB+eTlWLD0uhU58iZwfzi1h3Oa7cLU7Ol6nqyJ+0Cq2PgPgYjkKjags NLCA== X-Gm-Message-State: AG10YOR1BcABalxrXtlaAETngOpDdCc6Ur9rSerGXm2nZWQczgQhcXFNZyyOJlW1ejIwz1fKWFsM+kEHBLuWEw== MIME-Version: 1.0 X-Received: by 10.28.98.84 with SMTP id w81mr436990wmb.57.1455939828145; Fri, 19 Feb 2016 19:43:48 -0800 (PST) Received: by 10.27.170.11 with HTTP; Fri, 19 Feb 2016 19:43:48 -0800 (PST) In-Reply-To: References: <201602182008.u1IK81vg092127@repo.freebsd.org> <20160219230612.GR1945@FreeBSD.org> Date: Fri, 19 Feb 2016 21:43:48 -0600 Message-ID: Subject: Re: svn commit: r295768 - head/usr.sbin/iostat From: Benjamin Kaduk To: cem@freebsd.org Cc: Gleb Smirnoff , Alan Somers , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Sergey Kandaurov , "src-committers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 03:43:50 -0000 On Fri, Feb 19, 2016 at 6:50 PM, Conrad Meyer wrote: > On Fri, Feb 19, 2016 at 3:14 PM, Benjamin Kaduk wrote: > > On Fri, Feb 19, 2016 at 5:06 PM, Gleb Smirnoff > wrote: > >> Isn't zero filling part of the standard? I don't see why lack of > >> explicit zeroing is a warning? Looks a false warning to me. > > > > > > It is not quite as simple as this would make it sound. The elements or > > members of an aggregate (e.g.) structure type are initialized as if it > were > > an object of static storage duration (i.e., to zero) if the initializer > list > > does not contain enough initializers for all members of the aggregate > type, > > per item 21 of section 6.7.8 of n1256.pdf. However, such initialization > > does not necessarily need to zero any padding bytes that are present, > which > > may take unspecified values. Personally, I think this particular clang > > warning can be too aggressive, especially for complex structs, but on the > > other hand given the indeterminateness of padding, bzero/memset are > often a > > better choice anyway. > > > By definition, padding byte contents are unused. There is no reason > their values matter one way or another, so why do we care about the > distinction between bzero and member zero initialization? > Well, you can access them by treating the object as an array of char, and then memory sanitizer will complain about the uninitialized access, as in https://github.com/openssl/openssl/commit/f0496ad71fbacccf5a95f40d31d251bc8cf9dcfb -Ben P.S. Not really apropos of anything, but clang also has -Weverything which is just what it sounds like (as opposed to -Wall), which is a great way to expose several other warnings that Bruce will call bugs :)