bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Openat without die


From: Paul Eggert
Subject: Re: Openat without die
Date: Tue, 11 Jan 2011 10:32:15 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7

Regardless of the openat-die issue, it seems to me that
OPENAT_BUFFER_SIZE (currently 512) is too small.  I'd like
OPENAT_BUFFER_SIZE to be 4096, because in that case the entire xmalloc
versus malloc issue would be irrelevant in Linux, because
you can't open a file whose name's length is >= 4096, so we'd
never need to invoke either xmallor or malloc.  As I
understand it, though, you can't allocate buffers that large
safely on the stack in Linux (when, o when, will this get
fixed??!)

At least we can bump it up to 4032 or so.  (See comments below
for why "4032".  I installed this:

>From 0c24e3b1837fa65aa18ca24158367277b0daf01d Mon Sep 17 00:00:00 2001
From: Paul Eggert <address@hidden>
Date: Tue, 11 Jan 2011 10:26:56 -0800
Subject: [PATCH] openat: Increase OPENAT_BUFFER_SIZE from 512 to at least 1024

This avoids heap allocation for file names whose lengths are in
the range 512..1023, with the upper bound increasing to at most
4031 depending on the platform's PATH_MAX.  (We do not want
pathmax.h here as it might supply a non-constant PATH_MAX.)
* lib/openat-priv.h (SAFER_ALLOCA_MAX, SAFER_ALLOCA): New macros.
Perhaps they should be moved to malloca.h?
(OPENAT_BUFFER_SIZE): Use them.
---
 ChangeLog         |   11 +++++++++++
 lib/openat-priv.h |   22 +++++++++++++++++++++-
 2 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a4d5acc..f8cd305 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2011-01-11  Paul Eggert  <address@hidden>
+
+       openat: Increase OPENAT_BUFFER_SIZE from 512 to at least 1024
+       This avoids heap allocation for file names whose lengths are in
+       the range 512..1023, with the upper bound increasing to at most
+       4031 depending on the platform's PATH_MAX.  (We do not want
+       pathmax.h here as it might supply a non-constant PATH_MAX.)
+       * lib/openat-priv.h (SAFER_ALLOCA_MAX, SAFER_ALLOCA): New macros.
+       Perhaps they should be moved to malloca.h?
+       (OPENAT_BUFFER_SIZE): Use them.
+
 2011-01-10  Bruno Haible  <address@hidden>
 
        doc: Update users.txt.
diff --git a/lib/openat-priv.h b/lib/openat-priv.h
index 6cbf630..948b220 100644
--- a/lib/openat-priv.h
+++ b/lib/openat-priv.h
@@ -21,9 +21,29 @@
 #define _GL_HEADER_OPENAT_PRIV
 
 #include <errno.h>
+#include <limits.h>
 #include <stdlib.h>
 
-#define OPENAT_BUFFER_SIZE 512
+/* Maximum number of bytes that it is safe to allocate as a single
+   array on the stack, and that is known as a compile-time constant.
+   The assumption is that we'll touch the array very quickly, or a
+   temporary very near the array, provoking an out-of-memory trap.  On
+   some operating systems, there is only one guard page for the stack,
+   and a page size can be as small as 4096 bytes.  Subtract 64 in the
+   hope that this will let the compiler touch a nearby temporary and
+   provoke a trap.  */
+#define SAFER_ALLOCA_MAX (4096 - 64)
+
+#define SAFER_ALLOCA(m) ((m) < SAFER_ALLOCA_MAX ? (m) : SAFER_ALLOCA_MAX)
+
+#if defined PATH_MAX
+# define OPENAT_BUFFER_SIZE SAFER_ALLOCA (PATH_MAX)
+#elif defined _XOPEN_PATH_MAX
+# define OPENAT_BUFFER_SIZE SAFER_ALLOCA (_XOPEN_PATH_MAX)
+#else
+# define OPENAT_BUFFER_SIZE SAFER_ALLOCA (1024)
+#endif
+
 char *openat_proc_name (char buf[OPENAT_BUFFER_SIZE], int fd, char const 
*file);
 
 /* Trying to access a BUILD_PROC_NAME file will fail on systems without
-- 
1.7.3




reply via email to

[Prev in Thread] Current Thread [Next in Thread]