Date: Sun, 26 Aug 2001 11:15:20 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.