www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/11/08/09:46:10

Date: Wed, 8 Nov 1995 14:50:16 +0300
From: "Alexander V. Lukyanov" <lav AT video DOT yars DOT free DOT net>
To: eliz AT is DOT elta DOT co DOT il
Cc: dj, djgpp AT sun DOT soe DOT clarkson DOT edu, jkmarsha AT socs DOT uts DOT edu DOT au,
kagel AT ts1 DOT bloomberg DOT com, lav AT yars DOT free DOT net
Subject: Re: CR/LF pairs... NO NO NO!

> Date: Wed, 8 Nov 1995 13:20:57 +0200 (IST)
> From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
> 
> On Wed, 8 Nov 1995, Alexander V. Lukyanov wrote:
> 
> > Well, I have just seen sources of libc for djgpp, and I've found,
> > that djgpp has the same bug I described before. Stdio converts
> > text back to raw format to calculate ftell(),
> > and if text in buffer contained plain '\n' then single '\n' will
> > be converted to two characters "\r\n". This is wrong, because
> > '\n' could be get from "\r\n" and from single '\n'.
> > This is why ftell() can tell wrong value.
> 
> Did you try this lately with a test program?  I didn't, but at least 

I didn't too... I just look at sources. I saw the effect in BorlandC.
I feel I should test my old program with djgpp.

> looking at the library sources shows that ftell() indeed assumes there 
> was a CR for every LF, but fseek() makes the same assumption, so if you 
> only call fseek() with values returned by ftell(), they should work.
> 
fseek uses this assumption only if the target position is in
data in buffer. Otherwise, it just fflush() the stream and does lseek(),
as far I can see.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019