🚀 go-pugleaf

In article <1992Dec29.212344.20899@qb.rhein-main.de> vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:


>Or did he mix it up with M$-DOS fseek on files opened in "text mode".
>This is indeed incredibly slow because the file is searched for CR/LFs
>since CR/LFs count as only one byte (a logical linefeed) in that case.

This is just plain wrong. 

A seek to a location in a text file is no slower than in a binary file.

This is because the location ... the number that the fseek is to ...
can be to a number of bytes in the file ... one does **not** need to
take into account the CRLF pairs. An fseek can **only** be to one of three
places:

1) the beginning

2) the end

3) the value returned by a previous ftell. 

The first two are trivial.

The third is also trivial ... as the ftell will never be in the middle of
the crlf pair. Ftell will normally return not **the number characters 
read by single getc's up to the given location** but rather the
**number of bytes physically returned from the file on disk**.

EXAMPLE:

the following program:

#include <stdio.h>
main()
{
int i,k;
long j;
for(i = 0; i < 7; i++) {
  k = getchar();
  j = ftell(stdin);
  printf("%d %d %ld\n",i,k,j);
}
}

When fed the following input file as stdin:

1
2
3
456

produces the following output:

0 49 1
1 10 3
2 50 4
3 10 6
4 51 7
5 10 9
6 52 10

Note that the crlf pairs increment the ftell results by two for one
read by getchar.


Doug McDonald