From: Peter Gerwinski <peter AT gerwinski DOT de>
Message-Id: <199804051917.VAA22728@esmeralda.gerwinski.de>
Subject: Re: I/O problems
In-Reply-To: <Pine.SUN.3.91.980405195934.6925A-100000@is> from Eli Zaretskii at "Apr 5, 98 08:05:09 pm"
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 5 Apr 1998 21:17:45 +0200 (MEST)
Cc: djgpp-workers AT delorie DOT com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hello!

`mktemp()' seems to work, but this does not solve the problem:

When `gpc.exe' (or `gcc.exe' for that matter) chooses a new
temporary file, it chooses one base name (say, "ccaaaaaa") and
appends several suffixes to it ("ccaaaaaa.i", "ccaaaaaa.s", etc.).

Now a second instance of `gpc.exe' starts work and tries to
choose a new temporary base name.  Since no file "ccaaaaaa"
(without suffix) exists, `mktemp()' has no problems returning
the same pattern again.

I can think of three solutions:

  1) `mktemp()' looks for "ccaaaaaa.*" rather than for just
     "ccaaaaaa",
     
  2) `gpc1.exe' creates a dummy "ccaaaaaa", so `mktemp()' will
     find it, or

  3) `gpc1.exe' does something else (e.g. does not use `mktemp()')
     to ensure that all base names are unique.

I consider (3) a kludge.  If there is a wider interest in a changed
behaviour of `mktemp()' I'd vote for (1), otherwise for (2) which
is probably the easiest way.

(Hmm ... why does this problem only show up with DJGPP, not with
other systems such as Linux?)

    Peter