Mail Archives: djgpp-workers/2000/05/26/14:19:39
On 26 May 2000, at 19:36, Eli Zaretskii wrote:
> > 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.
Looked sources in gcc2952s.zip (latest update not ones uploaded to
ftp.delorie.com, but I haven't changed any related thing for along time)
There is possibility of some problems:
Let assume gcc tries to create file in TMPDIR=c:/tmp and directory
with the same name already exist there. Then it gets EPERM (If there is
busy file I got EEXIST at least in DOS session under Win98 SE). That
is rather unlikely as biostime() is used to generate first file name (and
it's later incremented). In this case (BUG) it's assumed that directory is
bad and it quits the loop. Function mkstemp() in libc also has this
problem (if it gets EPERM it quits the loop)
Perhaps mkstemp should use stat() if it gets EPERM to verify whether
file (or directory) exists and and only give up if it's doen't exist.
Anyway I think that running into this problem is very unlikely
Andris
- Raw text -