From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] hvmloader/smbios: Change strncpy to memcpy for anchor strings. Date: Thu, 26 Sep 2013 20:13:19 +0100 Message-ID: References: <52443C08.5050108@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VPH0E-00045C-1L for xen-devel@lists.xenproject.org; Thu, 26 Sep 2013 19:13:30 +0000 Received: by mail-wi0-f176.google.com with SMTP id cb5so7570053wib.9 for ; Thu, 26 Sep 2013 12:13:28 -0700 (PDT) In-Reply-To: <52443C08.5050108@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel , Paul Durrant , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 26/09/2013 14:52, "Andrew Cooper" wrote: >>>>> - strncpy(ep->anchor_string, "_SM_", 4); >>>>> + memcpy(ep->anchor_string, "_SM_", sizeof(ep->anchor_string)); >>>> Why the change from 4 to sizeof(ep->anchor_string) here (and similar >>>> below)? >>>> Setting the copy length based on the size of the destination rather than >>>> the >>>> source seems like the wrong thing to do. >>> One can argue either way here: >>> - passing the destination's size guarantees no memory corruption >>> - passing the source's size guarantees no uninitialized memory >>> >>> Since the structure fields involved here aren't going to change, >>> either way is fine imo. >> As was the unadorned number 4, imo. >> >> -- Keir >> >> > > So what is the verdict here? I changed 4 to sizeof to match the > prevailing style of other anchor strings in hvmloader. > > I can resubmit and change back to hard coded numbers if that would cause > the patch to be accepted. Oh I don't care that much, though I would have left as hard coded numbers. Did I give an Ack yet? Here you can have one: Acked-by: Keir Fraser -- Keir