Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1767088imm; Thu, 12 Jul 2018 07:31:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfzpbbxsfQFWauIqzDVawHAA/fGIDOTCBc7dJ3S+vKZh9pTCt21H3CPEVdoYkGfVs5oSguJ X-Received: by 2002:a62:1d97:: with SMTP id d145-v6mr2719490pfd.101.1531405911164; Thu, 12 Jul 2018 07:31:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531405911; cv=none; d=google.com; s=arc-20160816; b=EmDOK3G14N4cwjl/pmUuOXjme2MSmX4E/CHbnQtlzld8zioY4IfIT/z7xeg4fZQWTo UZbprI5ah1+bVV819XNHFgsFxdUAjjxV5sSrnJ4wXPbG+TSWkSRvCFswNQqEJ14N38Rx hZch19NpjbxguQwXy6txeYW7rdInwAKangn8MNmgGs1KEiNizsbJ+jODm2xyMTgCP8S7 hTNiujteQJgDKuceo1WtZD+EerEBTlJp9BdwY4cmkbTkE2zo4HyWGpf8uhlOCLPUOHTs ZboCinuV3AJh/c8hAbt/jHUzhv82ohuMGqpq/rQWplH9yURLMAK0o+rbBRIyJA2IYOkc UbCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=58i5JRr1lP3P9TNIKOqq1hnc4smu11h90JdIih8fL6g=; b=Bx/xn13RScTJzFM9hmJkJwkUhci5ZTQ4lSJditXTo3OKcM3slx722C5Ey0Qfh19mZe Vm0C9P1YE99XX3ho1NLeeZfqmGe9Tb8FyVKNoZNh3tf8b4/zPMJtiI+NIn+EOZVs81Gq 3iYpynJwA/BepgAntZmLvqVXlNM6PZ01341+WPCosMDBLdz/bymMU8yyJytSETh/9xqa WiqGg6ZOMHny7UzK/wDD6hFi8LwhuxhDTO4xGv+wWE5KkAhysJZGhon50+vp5BNkCLkM lpUDMsfkNI2bzQGASbt4ZsU/IEbyk8wDXOzg5hep7Y8sSP4jODhYemranRT2Zh/TQefU RFYg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u188-v6si7576314pgu.256.2018.07.12.07.31.34; Thu, 12 Jul 2018 07:31:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732408AbeGLOkp (ORCPT + 99 others); Thu, 12 Jul 2018 10:40:45 -0400 Received: from nautica.notk.org ([91.121.71.147]:56936 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727094AbeGLOko (ORCPT ); Thu, 12 Jul 2018 10:40:44 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 1A04FC009; Thu, 12 Jul 2018 16:30:52 +0200 (CEST) Date: Thu, 12 Jul 2018 16:30:37 +0200 From: Dominique Martinet To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] i915/intel_tv_get_modes: fix strncpy truncation warning Message-ID: <20180712143037.GA15484@nautica> References: <1531295175-24052-1-git-send-email-asmadeus@codewreck.org> <20180712124401.GZ5565@intel.com> <20180712135526.GA5463@nautica> <20180712141015.GD5565@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180712141015.GD5565@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ville Syrjälä wrote on Thu, Jul 12, 2018: > On Thu, Jul 12, 2018 at 03:55:26PM +0200, Dominique Martinet wrote: > > This could either be 'this commit' as a whole or if you look only at the > > commit message 'this strncpy fix' from the title (which is arguably the > > same), and both interpretations sound fairly understandable in the > > context of the title line without seeing the patch to me... Although > > I'll admit this is difficult to judge of that as the author. > > The patch subject is not part of the commit message body though. This is > made all the more clear when I'm editing the response in vim that doesn't > even show the mail subject to me. Hence I'm always left in the dark by > commit messages that aren't fully self contained. Ah, that is a fair point - I thought you were referring to the patch itself, not the subject. My mail client does include the subject in the editor so I hadn't considered that, but I understand where you come from now and agree. I will be more mindful of that as the v2 has the same problem. > > Yes and no, I gave it for referrence but when you update to gcc 8 you > > will literally see it all over the place. > > The words "strncpy truncation warning" is really precise once you've > > seen them a few times and there are litteraly hundred of these warnings > > in the kernel, some have already been fixed taking a glance at the git > > log, some with and without the warning message. > > I don't think it's worth polluting the git log with this many > > warnings... Which leads to... > > I disagree. Without knowing what exactly is fixed how can you judge > whether the patch even makes sense? And later you may get another > report of the same warning and then you would want to look through > the git log to see if there's a patch that already fixed it. Quite > hard to do without the exact warning in the log. I might just be tired of this specific warning; I've fixed it countless times in different projects these past few months and it's coming out of my eyes at this point. I definitely agree in general, just -Wstringop-truncation has been showing up everywhere and it's always the same, with many occurences I don't consider to be bugs (like here because we forcefully terminate the last byte of the string afterwards), so it's really lost value to me. I included it as a comment precisely for your first point (so you can tell the patch makes sense now) but I do not feel any regret not recording it, and I still stand by what I said: if all you want is examples of patches that already fix it, I've just had a look at git log in drm trees and there already have been many fixes, most of which provided a warning similar to the one I got. Attaching the full warning messages makes sense if the warning is new/rare but if it's the same as 5 other commits in semi-recent history I do not see much point. Anyway, I would be enclined to add it just to comply now but it looks like Chris already picked the v2 up, so there is not much point in arguing, sorry for disagreeing. -- Dominique Martinet