[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: avoid mktemp/mkstemp internally
From: |
Mike Frysinger |
Subject: |
Re: avoid mktemp/mkstemp internally |
Date: |
Mon, 16 May 2016 10:36:01 -0400 |
On 16 May 2016 10:02, Chet Ramey wrote:
> On 5/13/16 2:40 PM, Mike Frysinger wrote:
> > i was pointed at a bug report for FreeBSD systems [1] where running lots
> > of processes in parallel would randomly fail with errors like:
> > cannot make pipe for process substitution: File exists
> >
> > upstream FreeBSD addressed this by defining USE_MKTEMP [2] & USE_MKSTEMP
> > [3] when building bash. looking at the source in bash though, i can't
> > see why these aren't always defined. why does bash try to reimplement
> > both funcs ad-hoc instead of just using the stable/guaranteed system
> > versions ?
>
> Because many traditional implementations of mktemp/mkstemp suck.
and many modern implementations work perfectly fine. why is the default
to penalize good/fixed versions ? how about we flip this in config-top.h
like the attached patch ?
> > the bash versions seem like it's pretty trivial to collide: it mixes
> > current seconds count, current pid number, and a counter.
>
> Not quite; the calls in bash mix in the return value from the system's
> random(). Now, if that sucks too, you're going to lose.
except bash isn't calling srand anywhere that i can see, so you're
iterating over the same values every time. i'm not sure how this
implementation wouldn't also fall into the "inferior" bucket.
-mike
--- a/config-top.h
+++ b/config-top.h
@@ -152,3 +152,9 @@
/* Define to the maximum level of recursion you want for the source/. builtin.
0 means the limit is not active. */
#define SOURCENEST_MAX 0
+
+/* Define if your mktemp implementation is sane. */
+#define USE_MKTEMP
+
+/* Define if your mkstemp implementation is sane. */
+#define USE_MKTEMP
signature.asc
Description: Digital signature