From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108251959.AA14007@clio.rice.edu>
Subject: Re: gcc-3.0.1 WinXP and lfn=n
To: djgpp-workers AT delorie DOT com
Date: Sat, 25 Aug 2001 14:59:15 -0500 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
In-Reply-To: <7263-Sat25Aug2001104519+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 25, 2001 10:45:20 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > I changed d:\djgpp\bin in specs to c:\djgpp\bin and I can now compile with
> > lfn=n ... 
> 
> What specs did you mean here?  

\djgpp\lib\gcc-lib\djgpp\3.01\specs
in the md_exec_prefix: section

also, here are the outputs from the compilers (gcc --print-search-dirs)

install: $DJDIR/lib/gcc-lib/djgpp/2.953/
programs: c:/djgpp/lib/gcc-lib/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/bin/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/bin/;c:/djgpp/bin/djgpp/2.953/;c:/djgpp/bin/
libraries: c:/djgpp/lib/djgpp/2.953/;c:/djgpp/lib/;c:/djgpp/lib/gcc-lib/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/lib/djgpp/2.953/;c:/djgpp/lib/gcc-lib/djgpp/2.953/$DJDIR/djgpp/lib/;c:/djgpp/bin/djgpp/2.953/;c:/djgpp/bin/;c:/djgpp/lib/djgpp/2.953/;c:/djgpp/lib/

install: c:/djgpp/lib/gcc-lib/djgpp/3.01/
programs: =c:/djgpp/lib/gcc-lib/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/;/usr/lib/gcc/djgpp/3.01/;/usr/lib/gcc/djgpp/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/bin/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/bin/;d:/djgpp/bin/djgpp/3.01/;d:/djgpp/bin/
libraries: =c:/djgpp/lib/djgpp/3.01/;c:/djgpp/lib/;c:/djgpp/lib/gcc-lib/djgpp/3.01/;/usr/lib/gcc/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/lib/djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/lib/;d:/djgpp/bin/djgpp/3.01/;d:/djgpp/bin/;c:/djgpp/lib/djgpp/3.01/;c:/djgpp/lib/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../djgpp/3.01/;c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../;/lib/djgpp/3.01/;/lib/;/usr/lib/djgpp/3.01/;/usr/lib/

The 2.953 version doesn't have any long paths, the 3.01 version does.  I hope
that doesn't cause anyone problems - the 3.01 library path line is 456 chars
long.

> > I wrote a small test program - and now I can kill NTVDM with a nice crash
> > box.  The long SFN kills the "16-bit dos subsystem."
> 
> Can you post this program?

#include <stdio.h>
#include <sys/stat.h>

#define fil1 "c:/djgpp/tmp/../lib/gcc-lib/djgpp/3.01/../../../../djgpp/bin/djgpp/3.01/as.exe"
#define fil2 "c:/djgpp/lib/gcc-lib/djgpp/3.01/../../../../djgpp/bin/djgpp/3.01/as.exe"
#define fil3 "d:/djgpp/bin/djgpp/3.01/as.exe"
             
int main(int argc, char ** argv)
{
struct stat st;

if (stat (fil1, &st) < 0)
 printf("stat failed\n");
      
if (stat (fil2, &st) < 0)
 printf("stat failed\n");
      
if (stat (fil3, &st) < 0)
 printf("stat failed\n");

printf("exit OK\n");
}

This killed the dos-16 subsystem several times.  Now it seems to be
behaving (of course...)

> > Should we avoid sending very long strings to DOS?
> 
> How long is ``very long''?  DOS is supposed to be able to handle file
> names up to 80 characters, with some functions limited to just 64.

One of the names above is 78 characters.

> Another known DOS limit is 8 levels of subdirectories: some system
> calls fail if the file name is in a subdirectory more than 8 levels
> deep.  The above file name doesn't exceed this limit, unless they
> count them before canonicalization (with function 60h of Int 21h),
> which should remove all the "../" parts for the file name.

With the ..'s included there are 16 in the first path.  Maybe it 
doesn't like this.

> Can you find out what is the limit in this case that NTVDM doesn't
> like?

It does not seem to be reliable (sometimes fails, sometimes does not).
The combination of the 3 stat calls at least killed it several times
in the example program.

> Also, I'm not sure I understand: if the long string is the one which
> crashes NTVDM, how come removing d:/djgpp/bin from the list of
> directories GCC tries fixed the problem?  

Magic?  Because c:/ was found instead of being not ready?  Who knows.

> Finally, does the fact that the CD drive is empty have any importance?  
> What happens if you put a disk in there?

I can't test this anymore, since it now doesn't crash like it did yesterday.