Why does ftell() shows wrong position after fread()?

Question

I'm getting a very strange error while trying to read from a simple text file with c fread() call.
I made a very simple program to show that error:

int main(int argc ,char ** argv) {
  FILE* fh = fopen("adult.txt","r");
  if(fh==NULL){
    printf("error opening file\n");
    exit(0);
  }

  int s = 1000;
  printf("cur before=%d\n",ftell(fh));
  char* b = malloc (sizeof(char)*s);
  int k =fread(b,sizeof(char),s,fh);
  printf("cur after reading %d bytes =%d\n",k,ftell(fh));

  return EXIT_SUCCESS;
}

And what I get as output:

cur before=0
cur after reading 1000 bytes =1007

Is that normal? fread return the number '1000' but the cursor (with ftell()) shows 1007 and any help will be appreciated.

Gavriella

Answer 1

That's normal.

'\n' can be represented with two characters, so there is the skew you are getting.

If you don't want that to happen, open the finaly in binary mode.

Unfriendly

thank you, i didn't know that. But i don't get why the return of fread() is not the same as the cursor position? – Gavriella

@Gavriella Because fread will interpret the end of line (which can be two characters) as one character, and report it as one. – Hephzipah

Answer 2

From the documentation of ftell:

or binary streams, the value returned corresponds to the number of bytes from the beginning of the file. For text streams, the value is not guaranteed to be the exact number of bytes from the beginning of the file, but the value returned can still be used to restore the position indicator to this position using fseek.

So yes, this is normal.

Vaientina

Answer 3

Let_Me_Be's answer is correct. I am just explaining here that the 'End of Line' (EOL) character is dependent to the underlying Operating System. For example, in Windows if you open a file with 'r' (or not Binary) then whenever there's a sequence of '\r\n' the OS will return only '\n'. Same way, when you write in a file which is not opened in binary mode then in Windows it will write '\r\n' when you simply write '\n'. For Unix systems there's no such translation by OS is done. Classic Macs would use '\r' for End of Line character, but I think now they use '\n' for EOL. I hope that clears the buzzword of '\n' to be represented (possibly) by multiple characters (\r\n).

Subaxillary