Re: Problem with version 3.12, NT4.0

[Valeriy E. Ushakov]

On Tue, Apr 21, 1998 at 12:35:58PM +0200, Thomas Steffen wrote:

> i have a problem with lout version 3.12 on NT4.0 using Cygnus WinGCC
> B19.1.
> 
> trying to compile the user guide, the 2nd run is terminated with the
> error message:
> 
> all.ld: Database seems to be out of date.
> 
> i was able to track this down in the source code, and it seems to
> imply a version compatibility problem (which is nonsense, of course). 
> so what went wrong, or how can i go about tracking the problem down?
> 
> yes, i have tried the suggested STATFIX (?), but it doesn't change a
> thing.  

It looks like a bug in cygwin's stdio, as far as I can tell without
actually looking at their sources and wading through them with
debugger.

To brief you: Lout records file offsets for items in .ld file(s) into
.li file(s).  It uses ftell() for this.  On win32 there's a
text/binary distinction.  Since Lout uses double-buffered input it has
to correct ftold value with pointer arithmetic.  In VC runtime ftell
always returns real (binary) offsets, so my DB_FIX code adjusts the
pointer arithmetic accordingly.

Now the problem with cygwin is that their stdio seems broken wrt to
ftell().  Write a simple program that reads say 512 bytes from a text
file, save postion reported with ftell, fseek away to invalidate
cashed data in stdio structures(!), seek back to the saved position,
read some more bytes.  You'll see that the bytes you read are not
consecutive.

VC runtime fills stdio buffer than compress CRLF->LF which frees up
some space in the buffer, than it continues until the buffer is
filled.

OTOH it seems that cygwin always reads in 1k chunks but forgets to
adjust the file position returned by ftell() afterwards.

I wrote the program described few paragraphs above and run it on a
file with numbers from 1 to some N one on a line.

With VC the ftell reports 667 after reading 512 bytes, which is
667-512=155 bytes greater.  And indeed, the last byte read is the end
of 155'th line with gives that 155 extra CR's.

Now with cygwin it reports 738 - which is 738-512=226.  The byte #1024
is in the 227th line.

Testing with different numbers (actually, just spitting some debugging
output from Lout and comparing Unix, Win32/VC, and Win32/Cygwin)
confirms this numerology.

You can't really fix this because this behaviour depends not only on
the stdio chunk size but on the distribution of CRLF in the input
file.

When I was debugging Lout on NT for the first time and found what the
problem was I quickly wrote a test, run it with cygwin and concluded
that they don't need the fix.  It seems that I was wrong.

The only possible solution (if you really insist on compiling with
cygwin) is for Lout to read/write all the files in binary mode (by
redeifining macros in externs.h appropriately) and for you - to tune
your emacs to always use binary mode as well.

And of course you're welcome to download precompiled win32
distribution from my ftp archive. :-)

PS: By the way, it suddenly occured to me that the msvc run time dll
    should be packed with my distribution, or does it ships with
    Windows?

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen