Message-Id: <200005261637.TAA01181@mailgw1.netvision.net.il>
Date: Fri, 26 May 2000 19:36:31 +0200
Date: Fri, 26 May 2000 19:36:31 +0300
X-Mailer: Emacs 20.6 (via feedmail 8.1.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
To: pavenis AT lanet DOT lv
CC: djgpp AT delorie DOT com
In-reply-to: <392EBD54.13380.F946F1@localhost> (pavenis@lanet.lv)
Subject: Re: gcc djgpp stopped working
References: <NABBIGFLDHBJPALPKPAGKELCEJAA DOT jrl AT netcom DOT com> <392EBD54 DOT 13380 DOT F946F1 AT localhost>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: pavenis AT lanet DOT lv
> Date: Fri, 26 May 2000 18:07:16 +0200
>
> > > From: "Dr. J. Robert Lee" <jrl AT netcom DOT com>
> > > Date: Fri, 19 May 2000 08:13:18 -0700
> > > 
> > > Thanks very much for pointing me in the right direction. The directory
> > > pointed to by TMPDIR had been magically changed into a file. I removed
> > > the file and re-created the directory. Now gcc works just fine.
> > 
> > I would suggest that the function that creates a temporary file return
> > some error indication, and GCC then would print a self-explanatory
> > error message, instead of aborting.  That would probably allow many
> > users to find the problem by themselves, instead of asking the gurus...
> 
> Tried to play with related things (breaking environment, renaming 
> c:/tmp, creating  plain file with such name etc) but failed to break gcc 
> and other stuff (no crashes or other weird things). For example gcc still 
> used root directory for placing temporary files. 

I don't know what are the exact circumstances where this problem
happens (I suspect that it involves a corrupt FAT or a FAT that was
corrupted and repaired by SCANDISK).  However, I do see 2 calls to
abort() in the function choose_temp_base; evidently one of them was
causing the crash.  What I suggested was that this function will print
a self-explanatory error message instead.

In general, a program should not abort if the problem could be solved
by user-level means (such as changing an environment variable),
renaming or deleting files, etc.  Aborting and dumping core should be
reserved for situations where the user cannot possibly help, like some
crazy inconsistency in internal data structures.