From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] hvmloader/smbios: Change strncpy to memcpy for anchor strings. Date: Thu, 26 Sep 2013 14:52:08 +0100 Message-ID: <52443C08.5050108@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VPBzI-0003v0-Pr for xen-devel@lists.xenproject.org; Thu, 26 Sep 2013 13:52:13 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: xen-devel , Paul Durrant , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 24/09/13 11:11, Keir Fraser wrote: > On 24/09/2013 10:39, "Jan Beulich" 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. ~Andrew