[musl] [RFC PATCH] implement strndupa

[musl] [RFC PATCH] implement strndupa

[Ismael Luceno]

Signed-off-by: Ismael Luceno <ismael@iodev.co.uk>
---
 include/string.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/string.h b/include/string.h
index 43ad0942edd5..fda7b2e4f57c 100644
--- a/include/string.h
+++ b/include/string.h
@@ -89,6 +89,7 @@ void explicit_bzero (void *, size_t);
 
 #ifdef _GNU_SOURCE
 #define	strdupa(x)	strcpy(alloca(strlen(x)+1),x)
+#define	strndupa(x, n)	strlcpy(alloca(strnlen((x), (n)), (x), (n))
 int strverscmp (const char *, const char *);
 char *strchrnul(const char *, int);
 char *strcasestr(const char *, const char *);
-- 
2.38.1

Re: [musl] [RFC PATCH] implement strndupa

[James Y Knight]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

>
>  #define        strdupa(x)      strcpy(alloca(strlen(x)+1),x)
> +#define        strndupa(x, n)  strlcpy(alloca(strnlen((x), (n)), (x), (n))


This causes the parameters to be evaluated multiple times -- and that is
also a problem with the existing strdupa. Unfortunately it's impossible to
implement these macros without multiple-evaluation, unless you use the GCC
statement-expression language extension (as glibc does).

IMO, musl should either use that extension, despite the general policy of
avoiding such non-standard language extensions, or simply not implement
these functions at all. Implementing them, but having them incorrectly
multiply-evaluate the parameters seems like the worst of the options...

[-- Attachment #2: Type: text/html, Size: 933 bytes --]

Re: [musl] [RFC PATCH] implement strndupa

[Rich Felker]

On Fri, Oct 21, 2022 at 06:09:42PM -0400, James Y Knight wrote:
> >
> >  #define        strdupa(x)      strcpy(alloca(strlen(x)+1),x)
> > +#define        strndupa(x, n)  strlcpy(alloca(strnlen((x), (n)), (x), (n))
> 
> 
> This causes the parameters to be evaluated multiple times -- and that is
> also a problem with the existing strdupa. Unfortunately it's impossible to
> implement these macros without multiple-evaluation, unless you use the GCC
> statement-expression language extension (as glibc does).
> 
> IMO, musl should either use that extension, despite the general policy of
> avoiding such non-standard language extensions, or simply not implement
> these functions at all. Implementing them, but having them incorrectly
> multiply-evaluate the parameters seems like the worst of the options...

These interfaces are basically *always a vuln* where used, and my
leaning would be that we should remove strdupa and not add strndupa so
as to get things using them fixed. The fact that they're macros and
not ABI makes this doable.

Rich