Message ID | 20230921-strncpy-drivers-iio-adc-stm32-adc-c-v1-1-c50eca098597@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5352133vqi; Thu, 21 Sep 2023 23:09:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGqKH/mnY3iLPJ1+ASHwa88SEc8BA7zo/WPejTzI4tiqK7ILGgX/CvPUScVvLL1jBM5ZxgE X-Received: by 2002:a05:6a20:7348:b0:153:b16e:8db1 with SMTP id v8-20020a056a20734800b00153b16e8db1mr8259691pzc.10.1695362943025; Thu, 21 Sep 2023 23:09:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695362943; cv=none; d=google.com; s=arc-20160816; b=oOOAttOPmnTA/SRSMzzOx89dKr2F07znvoG2cZlwCO1XpBr/Upa8UE2Uo/DDGaDDLq 5SntXRPHCz7HXgUb1e3A9RgmTsAHOfNKALoWrJ22MVma6Sc4zZKxe+FwRSqMLtYRmavN el9ybwmhjlhwKTZukjsKptcYwy4Qspc6NYbtTQqnmNap8Eb5LFuI5QEbqHBASIgYUhF4 5meB1DDElSQd6eOOqTWm/CvevPbaFPfQqi897G89iNq2PxYGCd/5x4KSW4Dt2quyu2kb NVNRwFK1pKZr6688qPPZ0Nnivi/PAAg9Pg9qjLBO3e93/C0NnJfdDd1Zq+1wjt+B/ei5 SBqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=KBlJtLtsdI3hK0QdaI1JvF2kBovJQMFIeF0KITJB/xY=; fh=/58XTcRv9ojvLsGeIVDcxKQJCTRumF++sJKwKrd0UEM=; b=j//R9fKC9KlBvTXykBnc8BPG6qSlXcNLQKiDNBhsm90ifgcWXN6PWgD8m3C/gix0+P SGgIw2J+KemGfz4zKkIPyLEqR2aCJ7tCB5JJyE50CRyICqPlVALPgP6qwu/Ioby3dSoB +FnIOo2G6Z7Sl3RUfDZE2WnGlFkV7TcXTUsSWidN75TY7zIqBn6rHUyBi+UJreHsYyNr ntVIZuwh04x88I3MX/FysqNZ3XkmC9pgDmcJlMjkL0r2ehPMW/Hkxrk1jf048Vf84E2B 6gqAXCfhw++J7Qu5vRrhyJl1MRVdrDKQ2Nue6o0c4nyZpqWo9phsNEIGYQ043d2kow8e ZKCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=nOPHjrqB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id e9-20020a170902b78900b001c3f58d15aesi2988346pls.223.2023.09.21.23.09.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 23:09:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=nOPHjrqB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 7126080253B0; Thu, 21 Sep 2023 11:37:57 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229867AbjIUSh3 (ORCPT <rfc822;pwkd43@gmail.com> + 29 others); Thu, 21 Sep 2023 14:37:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230098AbjIUSgs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 21 Sep 2023 14:36:48 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2C40DB649 for <linux-kernel@vger.kernel.org>; Thu, 21 Sep 2023 11:32:39 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-59eea906b40so18811267b3.0 for <linux-kernel@vger.kernel.org>; Thu, 21 Sep 2023 11:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695321158; x=1695925958; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=KBlJtLtsdI3hK0QdaI1JvF2kBovJQMFIeF0KITJB/xY=; b=nOPHjrqBIGpQvEbyjHLhjS5j3oSFzKWpRTNcXv3ZiTZ1QUn6QonySbCQLpW7zhr5cV 8hSf6ZQZoaw3bkIxeWhJpBzVvtdJ5XIEnqJDx9i6edYps8+9FgYx3cM7ZfwQQV6oo6nN +TbOf+P6/LCHwpAwxjbpvAzFFD8e9YFpK4ZkU1zXxLKYg6YToajfXo1DPzS0YeBBZfF/ +WPpNCcN5zZ96FrI7H8YCktWklcudsIv52xBup4Zs27ucI6cmf1q4QIcx3am0n2RvedR X73itWfmcZW8FkDxPgES7hO3rnlBSQLglRatZCLQfoZcfQLZOfX+iOhGArxc9j80PmcC q4IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695321158; x=1695925958; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KBlJtLtsdI3hK0QdaI1JvF2kBovJQMFIeF0KITJB/xY=; b=YrIg83NqjqOWRqFXyhQA767Ruo/nE32HEE7MyMMGTVSKkyM9Rr7p9AEccCPXZ9A4PX NGHoauhDkFMCkX68pkjcJhX6R/6XL4mHSw/lRFWUaiV7eZcSfpMfDNnKzW1oD9/2DV/I Oo+1rGpizm/MNmI2hYeHxuV/8w3DlOdHa/VFQvx4Adfim861sciKqGJihNgmboC7iw9h shfEcPm00OnpsgqJUgA4zSXILCbYY6sM/7/9aVoVXEsA/SCJcR+ba+cr99sbl9wd66YF iX124s6bZZKeAIsH3wvx27+5uwcmYQLazr0KTIDdbYmU50uXCEIrasoHcp6kEoUUTlop joSg== X-Gm-Message-State: AOJu0Yx97i+qV5Hz4HlWQV2icnw4YlilKJaWsk1gGx86xRU/bAbsNUBB QvdwstRQUnpq2Fttmxmn7HVaY6Pg6P5xWtAqIA== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:4082:0:b0:d80:1391:1f1 with SMTP id n124-20020a254082000000b00d80139101f1mr63208yba.1.1695272040719; Wed, 20 Sep 2023 21:54:00 -0700 (PDT) Date: Thu, 21 Sep 2023 04:54:00 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAGfMC2UC/x2NSwqEMBAFryK9tsEkw4BeRVzk05nphVG6RRTx7 gZ3VbV47wIlYVIYmguEdlZeShXTNhD/vvwIOVUH21nX9dagblLiemIS3kkUmRf0KdY+O/tSRBN y777+k3MIUJdWoczH+zJO9/0A10IdAXUAAAA= X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1695272040; l=2097; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=wxLohCJ8OZyT4ckFvNL/ySlACAagL4RRycYgRdRDcQE=; b=FJozEDATUZfUMAdvAUx5oyW6ZiVUThemIA/jnMSx8yNUj5AxeA4RjStYDSxol7J7+D4rXF5CQ KDXN5IlUqusC1qJ5YHBdUIOWRiGU0IIeYHvhB5gxVpdkMBQYmxwb0L3 X-Mailer: b4 0.12.3 Message-ID: <20230921-strncpy-drivers-iio-adc-stm32-adc-c-v1-1-c50eca098597@google.com> Subject: [PATCH] iio: adc: stm32-adc: replace deprecated strncpy From: Justin Stitt <justinstitt@google.com> To: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: linux-iio@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-7.5 required=5.0 tests=DATE_IN_PAST_12_24, DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 21 Sep 2023 11:37:57 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777716893421300151 X-GMAIL-MSGID: 1777716893421300151 |
Series |
iio: adc: stm32-adc: replace deprecated strncpy
|
|
Commit Message
Justin Stitt
Sept. 21, 2023, 4:54 a.m. UTC
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
We should prefer more robust and less ambiguous string interfaces.
We expect adc->chan_name[val] to be NUL-terminated based on ch_name's
use within functions that expect NUL-terminated strings like strncmp and
printf-likes:
| if (!strncmp(stm32_adc_ic[i].name, ch_name, STM32_ADC_CH_SZ)) {
| /* Check internal channel availability */
| switch (i) {
| case STM32_ADC_INT_CH_VDDCORE:
| if (!adc->cfg->regs->or_vddcore.reg)
| dev_warn(&indio_dev->dev,
| "%s channel not available\n", ch_name);
...
There is no evidence that NUL-padding is needed either.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding. If, for any reason, NUL-padding _is_
required we should go for `strscpy_pad`.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
Note: build-tested
---
drivers/iio/adc/stm32-adc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
base-commit: 2cf0f715623872823a72e451243bbf555d10d032
change-id: 20230921-strncpy-drivers-iio-adc-stm32-adc-c-1bf936a4ffbb
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On Thu, Sep 21, 2023 at 04:54:00AM +0000, Justin Stitt wrote: > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > We should prefer more robust and less ambiguous string interfaces. > > We expect adc->chan_name[val] to be NUL-terminated based on ch_name's > use within functions that expect NUL-terminated strings like strncmp and > printf-likes: > | if (!strncmp(stm32_adc_ic[i].name, ch_name, STM32_ADC_CH_SZ)) { > | /* Check internal channel availability */ > | switch (i) { > | case STM32_ADC_INT_CH_VDDCORE: > | if (!adc->cfg->regs->or_vddcore.reg) > | dev_warn(&indio_dev->dev, > | "%s channel not available\n", ch_name); > ... > > There is no evidence that NUL-padding is needed either. Agreed -- it's used as a C string everywhere I can see. > > Considering the above, a suitable replacement is `strscpy` [2] due to > the fact that it guarantees NUL-termination on the destination buffer > without unnecessarily NUL-padding. If, for any reason, NUL-padding _is_ > required we should go for `strscpy_pad`. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Note: build-tested > --- > drivers/iio/adc/stm32-adc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c > index f7613efb870d..9cdcf396d901 100644 > --- a/drivers/iio/adc/stm32-adc.c > +++ b/drivers/iio/adc/stm32-adc.c > @@ -2209,7 +2209,7 @@ static int stm32_adc_generic_chan_init(struct iio_dev *indio_dev, > ret = -EINVAL; > goto err; > } > - strncpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > + strscpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); I still prefer sizeof($dst), but yes, these are the same: char chan_name[STM32_ADC_CH_MAX][STM32_ADC_CH_SZ]; If this needs a v2, please improve the Subject, but it is technically correct, so: Reviewed-by: Kees Cook <keescook@chromium.org> :) -Kees
On Sat, 23 Sep 2023 20:15:09 -0700 Kees Cook <keescook@chromium.org> wrote: > On Thu, Sep 21, 2023 at 04:54:00AM +0000, Justin Stitt wrote: > > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > > > We should prefer more robust and less ambiguous string interfaces. > > > > We expect adc->chan_name[val] to be NUL-terminated based on ch_name's > > use within functions that expect NUL-terminated strings like strncmp and > > printf-likes: > > | if (!strncmp(stm32_adc_ic[i].name, ch_name, STM32_ADC_CH_SZ)) { > > | /* Check internal channel availability */ > > | switch (i) { > > | case STM32_ADC_INT_CH_VDDCORE: > > | if (!adc->cfg->regs->or_vddcore.reg) > > | dev_warn(&indio_dev->dev, > > | "%s channel not available\n", ch_name); > > ... > > > > There is no evidence that NUL-padding is needed either. > > Agreed -- it's used as a C string everywhere I can see. > > > > > Considering the above, a suitable replacement is `strscpy` [2] due to > > the fact that it guarantees NUL-termination on the destination buffer > > without unnecessarily NUL-padding. If, for any reason, NUL-padding _is_ > > required we should go for `strscpy_pad`. > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-hardening@vger.kernel.org > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > --- > > Note: build-tested > > --- > > drivers/iio/adc/stm32-adc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c > > index f7613efb870d..9cdcf396d901 100644 > > --- a/drivers/iio/adc/stm32-adc.c > > +++ b/drivers/iio/adc/stm32-adc.c > > @@ -2209,7 +2209,7 @@ static int stm32_adc_generic_chan_init(struct iio_dev *indio_dev, > > ret = -EINVAL; > > goto err; > > } > > - strncpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > > + strscpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > > I still prefer sizeof($dst), but yes, these are the same: > > char chan_name[STM32_ADC_CH_MAX][STM32_ADC_CH_SZ]; > > If this needs a v2, please improve the Subject, but it is technically > correct, so: Hi Kees, I can tweak the subject whilst applying. What did you have in mind as a better one? Jonathan > > Reviewed-by: Kees Cook <keescook@chromium.org> > > :) > > -Kees >
On Sat, Sep 30, 2023 at 06:41:18PM +0100, Jonathan Cameron wrote: > On Sat, 23 Sep 2023 20:15:09 -0700 > Kees Cook <keescook@chromium.org> wrote: > > > On Thu, Sep 21, 2023 at 04:54:00AM +0000, Justin Stitt wrote: > > > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > > > > > We should prefer more robust and less ambiguous string interfaces. > > > > > > We expect adc->chan_name[val] to be NUL-terminated based on ch_name's > > > use within functions that expect NUL-terminated strings like strncmp and > > > printf-likes: > > > | if (!strncmp(stm32_adc_ic[i].name, ch_name, STM32_ADC_CH_SZ)) { > > > | /* Check internal channel availability */ > > > | switch (i) { > > > | case STM32_ADC_INT_CH_VDDCORE: > > > | if (!adc->cfg->regs->or_vddcore.reg) > > > | dev_warn(&indio_dev->dev, > > > | "%s channel not available\n", ch_name); > > > ... > > > > > > There is no evidence that NUL-padding is needed either. > > > > Agreed -- it's used as a C string everywhere I can see. > > > > > > > > Considering the above, a suitable replacement is `strscpy` [2] due to > > > the fact that it guarantees NUL-termination on the destination buffer > > > without unnecessarily NUL-padding. If, for any reason, NUL-padding _is_ > > > required we should go for `strscpy_pad`. > > > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > > Link: https://github.com/KSPP/linux/issues/90 > > > Cc: linux-hardening@vger.kernel.org > > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > > --- > > > Note: build-tested > > > --- > > > drivers/iio/adc/stm32-adc.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c > > > index f7613efb870d..9cdcf396d901 100644 > > > --- a/drivers/iio/adc/stm32-adc.c > > > +++ b/drivers/iio/adc/stm32-adc.c > > > @@ -2209,7 +2209,7 @@ static int stm32_adc_generic_chan_init(struct iio_dev *indio_dev, > > > ret = -EINVAL; > > > goto err; > > > } > > > - strncpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > > > + strscpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > > > > I still prefer sizeof($dst), but yes, these are the same: > > > > char chan_name[STM32_ADC_CH_MAX][STM32_ADC_CH_SZ]; > > > > If this needs a v2, please improve the Subject, but it is technically > > correct, so: > > Hi Kees, > > I can tweak the subject whilst applying. What did you have in mind > as a better one? I would use "iio: adc: stm32-adc: Replace deprecated strncpy() with strscpy()" Thanks! -Kees
On Sat, 30 Sep 2023 10:57:03 -0700 Kees Cook <keescook@chromium.org> wrote: > On Sat, Sep 30, 2023 at 06:41:18PM +0100, Jonathan Cameron wrote: > > On Sat, 23 Sep 2023 20:15:09 -0700 > > Kees Cook <keescook@chromium.org> wrote: > > > > > On Thu, Sep 21, 2023 at 04:54:00AM +0000, Justin Stitt wrote: > > > > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > > > > > > > We should prefer more robust and less ambiguous string interfaces. > > > > > > > > We expect adc->chan_name[val] to be NUL-terminated based on ch_name's > > > > use within functions that expect NUL-terminated strings like strncmp and > > > > printf-likes: > > > > | if (!strncmp(stm32_adc_ic[i].name, ch_name, STM32_ADC_CH_SZ)) { > > > > | /* Check internal channel availability */ > > > > | switch (i) { > > > > | case STM32_ADC_INT_CH_VDDCORE: > > > > | if (!adc->cfg->regs->or_vddcore.reg) > > > > | dev_warn(&indio_dev->dev, > > > > | "%s channel not available\n", ch_name); > > > > ... > > > > > > > > There is no evidence that NUL-padding is needed either. > > > > > > Agreed -- it's used as a C string everywhere I can see. > > > > > > > > > > > Considering the above, a suitable replacement is `strscpy` [2] due to > > > > the fact that it guarantees NUL-termination on the destination buffer > > > > without unnecessarily NUL-padding. If, for any reason, NUL-padding _is_ > > > > required we should go for `strscpy_pad`. > > > > > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > > > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > > > Link: https://github.com/KSPP/linux/issues/90 > > > > Cc: linux-hardening@vger.kernel.org > > > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > > > --- > > > > Note: build-tested > > > > --- > > > > drivers/iio/adc/stm32-adc.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c > > > > index f7613efb870d..9cdcf396d901 100644 > > > > --- a/drivers/iio/adc/stm32-adc.c > > > > +++ b/drivers/iio/adc/stm32-adc.c > > > > @@ -2209,7 +2209,7 @@ static int stm32_adc_generic_chan_init(struct iio_dev *indio_dev, > > > > ret = -EINVAL; > > > > goto err; > > > > } > > > > - strncpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > > > > + strscpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); > > > > > > I still prefer sizeof($dst), but yes, these are the same: > > > > > > char chan_name[STM32_ADC_CH_MAX][STM32_ADC_CH_SZ]; > > > > > > If this needs a v2, please improve the Subject, but it is technically > > > correct, so: > > > > Hi Kees, > > > > I can tweak the subject whilst applying. What did you have in mind > > as a better one? > > I would use "iio: adc: stm32-adc: Replace deprecated strncpy() with strscpy()" Makes sense. I also used the () approach to identify functions in the text of the patch description instead of `funcname` Applied with those tweaks to the togreg branch of iio.git but initially just pushed out as testing to let 0-day take a look at it. Thanks, Jonathan > > Thanks! > > -Kees >
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index f7613efb870d..9cdcf396d901 100644 --- a/drivers/iio/adc/stm32-adc.c +++ b/drivers/iio/adc/stm32-adc.c @@ -2209,7 +2209,7 @@ static int stm32_adc_generic_chan_init(struct iio_dev *indio_dev, ret = -EINVAL; goto err; } - strncpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); + strscpy(adc->chan_name[val], name, STM32_ADC_CH_SZ); ret = stm32_adc_populate_int_ch(indio_dev, name, val); if (ret == -ENOENT) continue;