Re: avoid mktemp/mkstemp internally

[Mike Frysinger]

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