[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Valeriy E. Ushakov
Subject: Re: Lout FAQ/HOWTO
Date: Fri, 31 Oct 1997 23:50:38 +0300

On Fri, Oct 31, 1997 at 01:37:33PM -0500, Chris Herborth wrote:

> > I wasn't aware of your problems.  Does QNX and BeOS has text/binary
> > file distinction?
> No, they don't, which is why I thought it was pretty odd.  Both have
> UNIX-style end-of-lines, etc.

Hmm, it seems that NT problem stems from text/binary distinction.  I
tried to vary BUFFER_SIZE and got different positions recorded in .li
file for different values.  The problem is that when fread() requests
BUFFER_SIZE bytes we actually get fewer from OS low level read()
becasue of squeezed crlf's.  So to fullfil the fread() request stdio
has to perform one more read that, as a side effect, will fill the
stdio internal buffer.  ftell() will then compensate for this
read-ahead and its logic is somewhat arcane.  I'm trying to figure out
what is going on in the VC stdio.

> > I've traced NT bug down to wrong return value from ftell() in
> > LexNextTokenPos() in z02.c that is solely responsible for wrong
> > offsets in .li files.
> Hmm... this shouldn't be a problem on either, stdio has been tested
> quite a bit on both platforms.  :-\
> I've just rebuilt lout 3.10 using the latest compiler/libs under QNX;
> when testing on the design document (lout.3.10/doc/design), the first
> pass completes fine, but the second pass aborts right away:
> address@hidden [535]: lout all > outfile.ps
> lout:
>          internal error: assert failed in SetOptimize: actual(res) !=
> Opt!
> ABORT instruction
> I'll do some more investigation to see if I can't figure out what's
> causing this.

Try compiling with debugging on and running with -dbs (or -ddbs, or
-dddbs) to see what is going on in DB subsytem.  You might want to
compare the output with the output obtained on a Unix system.  You
might want to check that .li files are identical on Unix and QNX as
.li file just records offsets in .ld file.

> > As a shotgun debugging measure, try to lower the BUFFER_SIZE in z02.c
> > (8k as shipped) to match your stdio buffering (4k in VC4.2).  Haven't
> > tried this, but going to ASAP.  (I'm hunting a nasty memory leak in
> > another program and it consumes most of my time).
> This didn't help at all, same results.  :-\

I tried it on NT.  When I change BUFFER_SIZE it results in changes in
.li files.  It's that damn text/binary brain death...

> > PS: Hmm, can you please send me a copy of standard.li you get after
> >     init run.  I'd like to compare it with the one I got on NT.
> Sure thing, I'll attach it to another email.

They are identical.  So I think your stdio (fread/ftell) is ok and the
cause of problem lies somewhere else.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]