mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] [RFC PATCH] implement strndupa
@ 2022-10-21 21:17 Ismael Luceno
  2022-10-21 22:09 ` James Y Knight
  0 siblings, 1 reply; 3+ messages in thread
From: Ismael Luceno @ 2022-10-21 21:17 UTC (permalink / raw)
  To: musl; +Cc: Rich Felker, 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] [RFC PATCH] implement strndupa
  2022-10-21 21:17 [musl] [RFC PATCH] implement strndupa Ismael Luceno
@ 2022-10-21 22:09 ` James Y Knight
  2022-10-22  0:26   ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: James Y Knight @ 2022-10-21 22:09 UTC (permalink / raw)
  To: musl; +Cc: Rich Felker, Ismael Luceno

[-- 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 --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [musl] [RFC PATCH] implement strndupa
  2022-10-21 22:09 ` James Y Knight
@ 2022-10-22  0:26   ` Rich Felker
  0 siblings, 0 replies; 3+ messages in thread
From: Rich Felker @ 2022-10-22  0:26 UTC (permalink / raw)
  To: James Y Knight; +Cc: musl, Ismael Luceno

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-10-22  0:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-21 21:17 [musl] [RFC PATCH] implement strndupa Ismael Luceno
2022-10-21 22:09 ` James Y Knight
2022-10-22  0:26   ` Rich Felker

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).