Message-ID: <B0000028948@stargate.astr.lu.lv>
From: "Andris Pavenis" <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Wed, 29 Apr 1998 14:18:04 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: mkstemp.c
CC: djgpp-workers AT delorie DOT com
References: <B0000028861 AT stargate DOT astr DOT lu DOT lv>
In-reply-to: <Pine.SUN.3.91.980429104206.1429D-100000@is>
Precedence: bulk

Date sent:      	Wed, 29 Apr 1998 10:43:13 +0300 (IDT)
From:           	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject:        	Re: mkstemp.c

> 
> On Tue, 28 Apr 1998, Andris Pavenis wrote:
> 
> > I think following is more safe. I think we should exclude other error codes
> > except EEXIST ( I tested that I'm getting this code even if there is
> > directory or R/O file with conflicting name, so all worked Ok).
> 
> This is one of the most painful problems.  Some network redirectors
> return weird error codes.  Let's do it your way and then wait and see.
> 

For libc.a such problems can be actual. For gcc I think we should avoid
putting temporary directory on network drive if possible. Unfortunatelly
my possibilities to test it is rather limited.

In suggested version (errno != ENOENT) program can go in unnecessary
loop on some I/O problem. Perhaps it would be better to post some test
example for checking this in different systems and ask to send the results.

One more thing. I'll generate initial name from value of biostime() so
probability of conflicts is not high. Here is one of the reasons why to provide
possibility to avoid these extra checks by specifying some environment
variable. So if some network redirector is doing something weird and we'll
really have to put temporary files on network drive than we'll have the option
to turn off this layer of protection against conflicts with some environement
variable ( set GCC_USE_MKSTEMP=n ). This is of course only for gcc but 
not for libc

> > Perhaps
> > I'll combine necessary procedures from 202 in one file (together with some
> > modifications especially for gcc) and use it as additional module
> > for building gcc (no more such ugly hacks as I talked before)
> 
> I suggest to patch the library you are using to link gcc on your
> machine with the new versions of mkstemp and with _creatnew.  Then put
> the sources of these functions inside the GCC source distribution and
> tell people in the README to compile them and put them into their
> libc.a before building GCC, unless they already have v2.02.  This is
> IMHO a better way.
> 

Perhaps better no. One additional file in config/i386 would be Ok. Requests
to modify something before building some package can be like a nightmare 
sometime... .I think all should be as simple as possible: 
      I'm giving already configured sources so 
        ./djmake.sh all
        ./djmake.sh install prefix=...
      must be enough (plus some additional editting)
Request to do additional operations will not make things better.

Andris