[Octave-bug-tracker] [bug #58055] ftell() incorrect on MS Windows platforms if file is not encoded with CRLF line endings

[John W. Eaton]

Follow-up Comment #15, bug #58055 (project octave):

I see strange results with some small programs that don't rely on Octave.  I
get reasonable results if using ftell/fseek but not if using _ftelli64 and
_fseeki64 (required to handle large files).

Here is the test program:


#include <stdio.h>

#if defined (LARGE_FILES)
typedef __int64 offset_type;
#define xftell ftello64
#define xfseek fseeko64
#else
typedef long offset_type;
#define xftell ftell
#define xfseek fseek
#endif

int main (void)
{
  int c;
  int line_count = 1;
  offset_type idx = 0;
  FILE *fid;

  fid = fopen ("foo.txt", "rt");
  printf ("initial pos: %ld\n", (long) xftell (fid));
  while ((c = fgetc (fid)) != EOF)
    {
      offset_type pos = xftell (fid);
      printf ("char: %d, pos: %ld\n", c, (long) pos);

      if (c == '\n' && ++line_count == 3)
        {
          idx = pos;
          printf ("found beginning of third line (idx = %ld)\n",
                  (long) idx);
        }
    }

  printf ("reading again from beginning of third line (idx = %ld)\n",
          (long) idx);

  if (xfseek (fid, idx, SEEK_SET) < 0)
    {
      printf ("SEEK FAILED!\n");
      return 1;
    }

  while ((c = fgetc (fid)) != EOF)
    printf ("char: %d, pos: %ld\n", c, (long) xftell (fid));

  fclose (fid);

  return 0;
}


The input file is just


f
o
o
b
a
r


using CRLF line endings.  The program is supposed to open the file for reading
in text mode, read the file one character at a time and display the characters
(as integers) and report file position after each character is read.  The
position of the beginning of the third line is saved, then after reading the
file once, the position is set to the saved position and the rest of the file
is read again.  When using ftell/fseek, I get the expected result:


initial pos: 0
char: 102, pos: 1
char: 10, pos: 3
char: 111, pos: 4
char: 10, pos: 6
found beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18
reading again from beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18
initial pos: 0
char: 102, pos: 1
char: 10, pos: 3
char: 111, pos: 4
char: 10, pos: 6
found beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18
reading again from beginning of third line (idx = 6)
char: 111, pos: 7
char: 10, pos: 9
char: 98, pos: 10
char: 10, pos: 12
char: 97, pos: 13
char: 10, pos: 15
char: 114, pos: 16
char: 10, pos: 18


Note that the file position jumps by two when it returns the LF character. 
That makes sense as it is skipping the CR character because the file was
opened in text mode.

But when using _ftelli64/_fseeki64, I see the following strange result:


initial pos: 0
char: 102, pos: 7
char: 10, pos: 8
char: 111, pos: 9
char: 10, pos: 10
found beginning of third line (idx = 10)
char: 111, pos: 11
char: 10, pos: 12
char: 98, pos: 13
char: 10, pos: 14
char: 97, pos: 15
char: 10, pos: 16
char: 114, pos: 17
char: 10, pos: 18
reading again from beginning of third line (idx = 10)
char: 10, pos: 14
char: 97, pos: 15
char: 10, pos: 16
char: 114, pos: 17
char: 10, pos: 18


WTF is the offset 7 after the first character is read?

Is _ftelli64 completely unreliable for files opened in text mode or am I
missing something?  I don't care what the numerical values of the offsets are,
but I believe we should be able to use  values from ftell to restore saved
file positions even when using files opened in text mode, at least if there
has been no change in file contents between the ftell and fseek.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58055>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/