Date:	Sun, 16 Feb 1997 09:51:43 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Douglas Rupp <rupp AT gnat DOT com>
cc:	djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject:	Re: fstat returns garbage
In-Reply-To:	<3305B8F6.3A3C5027@gnat.com>
Message-ID:	<Pine.SUN.3.91.970216094004.14977J-100000@is>
MIME-Version:	1.0

On Sat, 15 Feb 1997, Douglas Rupp wrote:

> This is on NT 4.0 w/ djgpp v2.01.
> 
> On a recursive call to make to bootstrap gnat1, the just-built compiler
> is getting bad information from fstat on it's first compilation for the
> second compiler, e.g. gcc -c -B../stage1 ...
> 
> fstat is returning a normal successful error code on a valid file
> descriptor for a regular file (ada.ads), but the st_mode field contains
> a value of 0x21a4 (a character special device??) and an st_size of 0
> bytes.

You will have to debug this a bit more, sorry.  I can understand weird 
things happening with st_mode, since `fstat' does some trickery to get at 
the attribute bits, but zero st_size?  That just seems impossible, since 
`fstat' simply calls `filelength' (which is just a call to DOS seek 
functions in disguise) to get the file size, so I fail to see how that 
could fail.  Can you step into `fstat' code, or put some debugging 
printf's there, and see what exactly happens in these cases?  Thanks.

My first gues would be that this is some bug in the DPMI host built into
NT (since restarting the whole thing makes it work).  As Charles would put
this: ``You didn't expect quality software from a virtual monopoly, did
you?''  NT's DPMI host is known to lose selectors when spawning child
processes, so maybe when `fstat' needs to use _dos_ds, it somehow fails
due to lack of selectors.  Charles? 

- Raw text -