public inbox for glibc-cvs@sourceware.org help / color / mirror / Atom feed
From: Samuel Thibault <sthibaul@sourceware.org> To: glibc-cvs@sourceware.org Subject: [glibc] hurd: writev: Get rid of alloca Date: Mon, 19 Jun 2023 00:45:28 +0000 (GMT) [thread overview] Message-ID: <20230619004528.836FB3858D28@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=cf30aa43a5917f441c9438aaee201c53c8e1d76b commit cf30aa43a5917f441c9438aaee201c53c8e1d76b Author: Joe Simmons-Talbott <josimmon@redhat.com> Date: Thu Jun 8 11:58:43 2023 -0400 hurd: writev: Get rid of alloca Use a scratch_buffer rather than alloca to avoid potential stack overflows. Checked on i686-gnu and x86_64-linux-gnu Message-Id: <20230608155844.976554-1-josimmon@redhat.com> Diff: --- sysdeps/posix/writev.c | 37 ++++++++++++++----------------------- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/sysdeps/posix/writev.c b/sysdeps/posix/writev.c index 53e090c087..d4c3cf6f03 100644 --- a/sysdeps/posix/writev.c +++ b/sysdeps/posix/writev.c @@ -19,19 +19,13 @@ #include <unistd.h> #include <string.h> #include <limits.h> +#include <scratch_buffer.h> #include <stdbool.h> #include <sys/param.h> #include <sys/uio.h> #include <errno.h> -static void -ifree (char **ptrp) -{ - free (*ptrp); -} - - /* Write data pointed by the buffers described by VECTOR, which is a vector of COUNT 'struct iovec's, to file descriptor FD. The data is written in the order specified. @@ -53,22 +47,17 @@ __writev (int fd, const struct iovec *vector, int count) bytes += vector[i].iov_len; } - /* Allocate a temporary buffer to hold the data. We should normally - use alloca since it's faster and does not require synchronization - with other threads. But we cannot if the amount of memory - required is too large. */ - char *buffer; - char *malloced_buffer __attribute__ ((__cleanup__ (ifree))) = NULL; - if (__libc_use_alloca (bytes)) - buffer = (char *) __alloca (bytes); - else - { - malloced_buffer = buffer = (char *) malloc (bytes); - if (buffer == NULL) - /* XXX I don't know whether it is acceptable to try writing - the data in chunks. Probably not so we just fail here. */ - return -1; - } + /* Allocate a temporary buffer to hold the data. Use a scratch_buffer + since it's faster for small buffer sizes but can handle larger + allocations as well. */ + + struct scratch_buffer buf; + scratch_buffer_init (&buf); + if (!scratch_buffer_set_array_size (&buf, 1, bytes)) + /* XXX I don't know whether it is acceptable to try writing + the data in chunks. Probably not so we just fail here. */ + return -1; + char *buffer = buf.data; /* Copy the data into BUFFER. */ size_t to_copy = bytes; @@ -86,6 +75,8 @@ __writev (int fd, const struct iovec *vector, int count) ssize_t bytes_written = __write (fd, buffer, bytes); + scratch_buffer_free (&buf); + return bytes_written; } libc_hidden_def (__writev)
reply other threads:[~2023-06-19 0:45 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230619004528.836FB3858D28@sourceware.org \ --to=sthibaul@sourceware.org \ --cc=glibc-cvs@sourceware.org \ /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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).