Date:	Sun, 26 Aug 2001 11:15:20 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: gcc-3.0.1 WinXP and lfn=n
In-Reply-To:	<10108260800.AA13716@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010826111036.3978O-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 26 Aug 2001, Charles Sandmann wrote:

> > > This killed the dos-16 subsystem several times.
> > 
> > Any idea which call kills it?  Is it the last one?
> 
> Hard to say for sure.  I know inside gdb xgcc always made the ntvdm go
> away on the third one.  The test program usually didn't print anything to
> the screen, which would indicate the first one.

Not necessarily: it's possible that the DOS box went away before the 
display subsystem had a chance to run its redisplay (which only happens 
once in a while).

Writing log messages to a disk file, and fsync'ing the handles, might be a 
more reliable way of tracking the execution.

> > > One of the names above is 78 characters.
> > 
> > Still on the right side of the limit, I think.  But since it's not 
> > consistently crashes on these names, I don't think we can draw any 
> > conclusions.
> 
> I think we are randomly lucky that the name was 78 characters generated
> by GCC build instead of 81 ...

No, that's not luck: function 60h is supposed to take care of this.  
That's how longish file names work on plain DOS, although we never make 
sure they are shorter than 80 characters.

> I think we would be better off finding why we get lots of ../ in 3.01 and
> didn't get any in 2.953 ... just to be safe...

That's a good thing, too; but we cannot depend on every package doing so: 
it would make the porter's job impossibly hard.

- Raw text -