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.

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.

Answer 2

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).

Answer 3

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.