From: Nathan Chancellor <nathan@kernel.org>
To: Andy Shevchenko <andy@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Ard Biesheuvel <ardb@kernel.org>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
llvm@lists.linux.dev, linux-efi@vger.kernel.org
Subject: Re: [PATCH RFC 2/2] wcslen() prototype in string.h
Date: Tue, 25 Mar 2025 14:45:16 -0700 [thread overview]
Message-ID: <20250325214516.GA672870@ax162> (raw)
In-Reply-To: <Z-LiWDbrEvVaTLZU@smile.fi.intel.com>
On Tue, Mar 25, 2025 at 07:05:28PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 25, 2025 at 09:58:47AM -0700, Nathan Chancellor wrote:
> > On Tue, Mar 25, 2025 at 06:17:34PM +0200, Andy Shevchenko wrote:
> > > On Tue, Mar 25, 2025 at 08:45:19AM -0700, Nathan Chancellor wrote:
>
> ...
>
> > > > Rename the efi function to avoid the conflict.
> > >
> > > Hmm... Why not split this to two, rename patch as a standalone makes sense to
> > > me even outside of this series.
> >
> > How so? If nls.h is not included in printk.c via string.h, which does
> > not happen without this series, what value does the rename have? I do
> > not mind splitting it up that way to keep things cleaner, I am just
> > wondering what would be the justification in the changelog (I guess just
> > that nls.h may get included in the future for some reason)?
>
> Inside this series the justification is obvious (a.k.a. the same), outside
> yes something like "Put EFI specific function to the respective namespace
> to avoid potential clash in the future when including another header."
Okay, sounds reasonable to me. This is what I ended up with for that
change, which will become patch one of the series.
From f79267c05d2853c034e2c490f171aed064b85dd6 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Tue, 25 Mar 2025 14:31:25 -0700
Subject: [PATCH] efi: libstub: Rename utf8_to_utf32() to avoid collision with
NLS version
A future change will add nls.h to string.h, which will break the libstub
build because NLS includes its own version of utf8_to_utf32():
drivers/firmware/efi/libstub/printk.c:27:5: error: static declaration of 'utf8_to_utf32' follows non-static declaration
27 | u32 utf8_to_utf32(const u8 **s8)
| ^
include/linux/nls.h:55:12: note: previous declaration is here
55 | extern int utf8_to_utf32(const u8 *s, int len, unicode_t *pu);
| ^
drivers/firmware/efi/libstub/printk.c:85:26: error: too few arguments to function call, expected 3, have 1
85 | c32 = utf8_to_utf32(&s8);
| ~~~~~~~~~~~~~ ^
include/linux/nls.h:55:12: note: 'utf8_to_utf32' declared here
55 | extern int utf8_to_utf32(const u8 *s, int len, unicode_t *pu);
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
Rename the libstub version since it is static to avoid the conflict.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/firmware/efi/libstub/printk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/libstub/printk.c b/drivers/firmware/efi/libstub/printk.c
index 3a67a2cea7bd..334f7e89845c 100644
--- a/drivers/firmware/efi/libstub/printk.c
+++ b/drivers/firmware/efi/libstub/printk.c
@@ -24,7 +24,7 @@ void efi_char16_puts(efi_char16_t *str)
}
static
-u32 utf8_to_utf32(const u8 **s8)
+u32 efi_utf8_to_utf32(const u8 **s8)
{
u32 c32;
u8 c0, cx;
@@ -82,7 +82,7 @@ void efi_puts(const char *str)
while (*s8) {
if (*s8 == '\n')
buf[pos++] = L'\r';
- c32 = utf8_to_utf32(&s8);
+ c32 = efi_utf8_to_utf32(&s8);
if (c32 < 0x10000) {
/* Characters in plane 0 use a single word. */
buf[pos++] = c32;
--
2.49.0
Then the first patch (which becomes the second) becomes:
diff --git a/include/linux/string.h b/include/linux/string.h
index 0403a4ca4c11..45e01cf3434c 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -7,6 +7,7 @@
#include <linux/cleanup.h> /* for DEFINE_FREE() */
#include <linux/compiler.h> /* for inline */
#include <linux/types.h> /* for size_t */
+#include <linux/nls.h> /* for wchar_t */
#include <linux/stddef.h> /* for NULL */
#include <linux/err.h> /* for ERR_PTR() */
#include <linux/errno.h> /* for E2BIG */
@@ -203,6 +204,7 @@ extern __kernel_size_t strlen(const char *);
#ifndef __HAVE_ARCH_STRNLEN
extern __kernel_size_t strnlen(const char *,__kernel_size_t);
#endif
+extern __kernel_size_t wcslen(const wchar_t *s);
#ifndef __HAVE_ARCH_STRPBRK
extern char * strpbrk(const char *,const char *);
#endif
diff --git a/lib/string.c b/lib/string.c
index eb4486ed40d2..1aa09925254b 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -21,6 +21,7 @@
#include <linux/errno.h>
#include <linux/limits.h>
#include <linux/linkage.h>
+#include <linux/nls.h>
#include <linux/stddef.h>
#include <linux/string.h>
#include <linux/types.h>
@@ -429,6 +430,16 @@ size_t strnlen(const char *s, size_t count)
EXPORT_SYMBOL(strnlen);
#endif
+size_t wcslen(const wchar_t *s)
+{
+ const wchar_t *sc;
+
+ for (sc = s; *sc != '\0'; ++sc)
+ /* nothing */;
+ return sc - s;
+}
+EXPORT_SYMBOL(wcslen);
+
#ifndef __HAVE_ARCH_STRSPN
/**
* strspn - Calculate the length of the initial substring of @s which only contain letters in @accept
---
with basically the same changelog.
I will send v2 either tomorrow afternoon or Thursday morning to give a
little more time for initial review/comments.
Thanks for the quick feedback!
Cheers,
Nathan
next prev parent reply other threads:[~2025-03-25 21:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 15:45 [PATCH 0/2] string.c: Add wcslen() Nathan Chancellor
2025-03-25 15:45 ` [PATCH 1/2] lib/string.c: " Nathan Chancellor
2025-03-25 15:45 ` [PATCH RFC 2/2] wcslen() prototype in string.h Nathan Chancellor
2025-03-25 16:17 ` Andy Shevchenko
2025-03-25 16:58 ` Nathan Chancellor
2025-03-25 17:05 ` Andy Shevchenko
2025-03-25 21:45 ` Nathan Chancellor [this message]
2025-03-26 0:33 ` Nathan Chancellor
2025-03-26 8:59 ` Andy Shevchenko
2025-03-26 15:37 ` Nathan Chancellor
2025-03-26 15:43 ` Andy Shevchenko
2025-03-26 8:52 ` Andy Shevchenko
2025-03-25 23:55 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250325214516.GA672870@ax162 \
--to=nathan@kernel.org \
--cc=andy@kernel.org \
--cc=ardb@kernel.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nick.desaulniers+lkml@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox