Date: Mon, 3 Jun 1996 14:16:10 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Jorrit Tyberghein <Jorrit DOT Tyberghein AT uz DOT kuleuven DOT ac DOT be>
Cc: DJGPP AT delorie DOT com
Subject: Re: fseek slow in DJGPP 2.0?
In-Reply-To: <31B29BA0.2F06@uz.kuleuven.ac.be>
Message-Id: <Pine.SUN.3.91.960603140830.21344O-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 3 Jun 1996, Jorrit Tyberghein wrote:

> Recently I upgraded from DJGPP 2.0beta3 to the non-beta version
> of DJGPP. When I recompiled my program with the new DJGPP it
> worked perfectly except for one thing. Some parts of the program
> appeared to be unbearably slow.
>
> I traced the problem down to the 'fseek' function. There are several
> places in my program where I scan a file while I only need several

The version of `fseek' that was in beta3 had a subtle bug when dealing 
with text files.  Therefore, it was replaced in the release with a 
version that is safer but much slower in some situations, because it just 
discards all the buffered characters and rereads them.  The reason for 
this is that, for text files, there is no way to know where those deleted 
CR characters were in the buffer, or even if they were there at all (it 
might have been a Unix-style text file).  The old buggy version broke 
some programs (like `patch') and had to be replaced very close to the 
release date, when there was no time to redesign the entire 
`fseek'/`ftell' machinery.

> Can I get the old behaviour back?

The next DJGPP release should have faster `fseek'.