From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD861CDB47E for ; Wed, 18 Oct 2023 10:17:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230415AbjJRKRf (ORCPT ); Wed, 18 Oct 2023 06:17:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229702AbjJRKRd (ORCPT ); Wed, 18 Oct 2023 06:17:33 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71DCEB0 for ; Wed, 18 Oct 2023 03:17:31 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-507be298d2aso2472584e87.1 for ; Wed, 18 Oct 2023 03:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1697624250; x=1698229050; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uMF9+XVbotmwlZkgFVQV7OtJV2XJqMd/UdMT31C9cZA=; b=x3K17i3/yuAxq4zKxvz9TLDR6x/1vjyPGdYLvFmKiVNii/N8xAAQEs3FP0SCXfz/4B krxMceRVw535nVRJOcN1h//chRvvJYj7jVcjmZmUpI2SdVhcTqwmo3LmZs71Qf3WG4Kx yBZIjmKTr3Ze+3RYVDWZeab6tCrZ7b0tccQHO9CNFYvfV3qNd6HySDb8HG1reT4vhQiu Q4vazcA5uQP+PaP/bI1t3G/TOJswodddeOBXeQUyxMl22D1bWQW+DanGPWN5j/2E0yhs yQb+nZ7QYKzxxqLnTUKUSgiNBUUNyX1jFkzL6YxwHNM5vWdm40mt/9QBiA8Ps0YN/aNf F3jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697624250; x=1698229050; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uMF9+XVbotmwlZkgFVQV7OtJV2XJqMd/UdMT31C9cZA=; b=uvi+nQivv51sO0ojJn4JSk0jWNYkIjn1JaCPTEixedDt5o+kmP9by4SPc4gRDWDeVx r+CNtiTF4kze9RSBCWYFXjvYrwNeHkaKB17ZaumVHCHIp+rLRn0vOOP5MyIGqUUE2kCC pyD5L+SScpjQbNQ8v61nWwLNN7gi7yGyIf9EI7XLajOrmKLPYr1+S+PbxXQOm8vJ6pd9 ScmZpDkNY+gYYI5HkusJavf9t9KECgJvODzF1CX9XADWA4pBnEuaHOPTkeXZ2BecFOXh 3yDTuxwTExUF2MsxNaoQszeSpcvF5VglIWuZH8e/hQBk8hv/vF3elgoeZX+nott/dhGq LJ9w== X-Gm-Message-State: AOJu0YyW29DFwnDGj94jojnxK1bWglZHhJGNLyq1UPB2Qsld2utpMCTN RavVWvRB6TeJu5VXL0RBZGCkbA== X-Google-Smtp-Source: AGHT+IHuHf/vAVlD/nYzbbKTFIUa4gHdOV6nXgpEc3kC6Vu1Tngn0aHuloTkDC1Ihtka7WkYH8MafA== X-Received: by 2002:a05:6512:3b89:b0:507:96fd:d3ee with SMTP id g9-20020a0565123b8900b0050796fdd3eemr4498644lfv.32.1697624249706; Wed, 18 Oct 2023 03:17:29 -0700 (PDT) Received: from localhost ([102.36.222.112]) by smtp.gmail.com with ESMTPSA id l6-20020a5d4806000000b0032da75af3easm1786409wrq.80.2023.10.18.03.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 03:17:28 -0700 (PDT) Date: Wed, 18 Oct 2023 13:17:25 +0300 From: Dan Carpenter To: Calvince Otieno Cc: gustavo@embeddedor.com, outreachy@lists.linux.dev, Greg Kroah-Hartman , Martyn Welch , Manohar Vanga , Julia Lawall , linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev Subject: Re: [PATCH] staging: vme_user: replace strcpy with strscpy Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2023 at 10:29:51AM +0300, Calvince Otieno wrote: > Checkpatch suggests using strscpy() instead of strncpy(). > > The advantages of strscpy() are that it always adds a NUL terminator > and prevents read overflows if the source string is not properly > terminated. One potential disadvantage is that it doesn't zero pad the > string like strncpy() does. You're not replacing strncpy(), you're replacing strcpy(). There is never a downside to replacing strcpy() with strspy() beyond that the secure function is probably slightly slower. > > In this code, strscpy() and strncpy() are equivalent and do not affect > runtime behavior. strscpy() simply copies the known string value of the > variable driver_name into the fake_bridge->name variable, which also > has a fixed size. > > While using strscpy() does not address any bugs, it is considered a better > practice and aligns with checkpatch recommendations. This analysis does not say where driver_name is set, or how big it is, or what the size of the fake_bridge->name buffer is. I would like to see that sort of analysis in the commit message. regards, dan carpenter