From: Rich Felker <dalias@libc.org>
To: "A. Wilcox" <AWilcox@Wilcox-Tech.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH v1] string.h: Unconditionally expose C23 functions
Date: Fri, 11 Jul 2025 13:04:27 -0400 [thread overview]
Message-ID: <20250711170427.GA1827@brightrain.aerifal.cx> (raw)
In-Reply-To: <3F6D3E56-2C3C-46D7-A742-826EE9214CD9@Wilcox-Tech.com>
On Fri, Jul 11, 2025 at 11:44:44AM -0500, A. Wilcox wrote:
> On Jul 11, 2025, at 08:47, Alejandro Colomar <alx@kernel.org> wrote:
> >
> > memccpy(3), strnlen(3), strdup(3), and strndup(3) are now specified by
> > ISO C, since C23.
> >
> > Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf>
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > ---
> > include/string.h | 13 +++++--------
> > 1 file changed, 5 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/string.h b/include/string.h
> > index 83e2b946..723cfc42 100644
> > --- a/include/string.h
> > +++ b/include/string.h
> > @@ -26,6 +26,7 @@ extern "C" {
> >
> > void *memcpy (void *__restrict, const void *__restrict, size_t);
> > void *memmove (void *, const void *, size_t);
> > +void *memccpy (void *__restrict, const void *__restrict, int, size_t);
> > void *memset (void *, int, size_t);
> > int memcmp (const void *, const void *, size_t);
> > void *memchr (const void *, int, size_t);
> > @@ -36,6 +37,9 @@ char *strncpy (char *__restrict, const char *__restrict, size_t);
> > char *strcat (char *__restrict, const char *__restrict);
> > char *strncat (char *__restrict, const char *__restrict, size_t);
> >
> > +char *strdup (const char *);
> > +char *strndup (const char *, size_t);
> > +
> > int strcmp (const char *, const char *);
> > int strncmp (const char *, const char *, size_t);
> >
> > @@ -52,6 +56,7 @@ char *strstr (const char *, const char *);
> > char *strtok (char *__restrict, const char *__restrict);
> >
> > size_t strlen (const char *);
> > +size_t strnlen (const char *, size_t);
> >
> > char *strerror (int);
> >
> > @@ -66,9 +71,6 @@ char *strtok_r (char *__restrict, const char *__restrict, char **__restrict);
> > int strerror_r (int, char *, size_t);
> > char *stpcpy(char *__restrict, const char *__restrict);
> > char *stpncpy(char *__restrict, const char *__restrict, size_t);
> > -size_t strnlen (const char *, size_t);
> > -char *strdup (const char *);
> > -char *strndup (const char *, size_t);
> > char *strsignal(int);
> > char *strerror_l (int, locale_t);
> > int strcoll_l (const char *, const char *, locale_t);
> > @@ -76,11 +78,6 @@ size_t strxfrm_l (char *__restrict, const char *__restrict, size_t, locale_t);
> > void *memmem(const void *, size_t, const void *, size_t);
> > #endif
> >
> > -#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) \
> > - || defined(_BSD_SOURCE)
> > -void *memccpy (void *__restrict, const void *__restrict, int, size_t);
> > -#endif
> > -
> > #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > char *strsep(char **, const char *);
> > size_t strlcat (char *, const char *, size_t);
> > --
> > 2.50.0
>
>
> These should not be unconditionally exposed because you can still
> build C99 or C11 code against musl.
>
> We actually already had to patch something like this *away* (in
> https://cgit.adelielinux.org/musl/commit/?id=41735bdeff548ce44afe21aa21f1345047eb18e4)
> to ensure no namespace pollution. Please don’t make it worse. Add ||
> __STDC_VERSION__ >= 202311L instead.
Generally we only attempt to conform strictly to latest version of the
relevant standard, not past versions. However in this case, the
namespace str* and mem* was already reserved, so I think even without
that policy, there's no reason not to expose them unconditionally
unless we're using strictness to expose non-conforming
application-side expectations.
Rich
next prev parent reply other threads:[~2025-07-11 17:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 13:47 Alejandro Colomar
2025-07-11 16:44 ` [musl] " A. Wilcox
2025-07-11 17:04 ` Rich Felker [this message]
2025-07-11 18:55 ` Thorsten Glaser
2025-07-11 20:50 ` James Y Knight
2025-07-11 22:41 ` A. Wilcox
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=20250711170427.GA1827@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=AWilcox@Wilcox-Tech.com \
--cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).