Thread: Very Very Weird Situation

Guys please check the following code.
It prints a file backwards, but has very weird behavior.
Whenever we reach to the beginning of the file,
We go back to the end and print the file over and over again! I don't understand how this could be, fseek() not allow to go back from the beginning.

I'm posting this code even that I've fixed the problem.
I still want to understand how can it be.

Code:

    fpRead=fopen("fileseek.c","rb");
	if (fpRead==NULL)
	{
		puts("File not found!");
		exit(1);
	}

	if (fseek(fpRead,-1L,SEEK_END))
	{
		puts("Error skipping file");
		exit(1);
	}


	while ((fread(&cReadByte,sizeof(char),1,fpRead)) && (ftell(fpRead)>0))
	{
	
		//printf("%ld\n",ftell(fpRead));
	                putchar(cReadByte);
		fseek(fpRead,-2,SEEK_CUR);
		
	}

If ftell is enabled the output will be something like this:
12
11
10
9
8
7
6
5
4
3
2
1
12
11
10
.
.
.

Many thanks

When your code gets to the beginning of the file, it will call fread() to read one character. At that point ftell() will return 1, not zero, because you have read one character from the beginning. So change your second test to ftell(fpRead) > 1.

Originally Posted by grumpy

When your code gets to the beginning of the file, it will call fread() to read one character. At that point ftell() will return 1, not zero, because you have read one character from the beginning. So change your second test to ftell(fpRead) > 1.

Still....
When the code reach to the beginning of the file and I call fread() then yes ftell() will return 1,
But I am using -2 in fseek() so the desribale result after calling ftell() will be -1, but it's not it is going to the end of the file again and loop to the beginning over and over.

The result of using fseek() to move before the beginning of a file is an error. Apart from the fact that your code is not testing for such an error, there is also the added complication that not all operating systems (or, more accurately, the disk management schemes associated with those operating systems) can actually detect that error.

In any event, a subsequent call of ftell() is not required to return -1 in such a circumstance: in practice, it is more likely to return either the value of the pointer before calling fseek() or it will return 0.

I would apprichiate it if someone will try to run the code.
I agree with all the replys, but running the code show otherwise, that's why I've post it!

Thanks again

Running this code:

Code:

while (fread(&cReadByte, sizeof(char), 1, fpRead) && ftell(fpRead) > 0)
{
   printf("%ld\n", ftell(fpRead));
   fseek(fpRead,-2,SEEK_CUR);
}

on SLES 10 (Linux), compiled with gcc, produces:

Code:

8
7
6
5
4
3
2
1
2
1
...

So I'm guessing the behavior of fseek, when seeking beyond the start of the file, is implementation-dependent.

i have run the code on tc2.0 it works fine...
the result is perfect.. no flaws...

and by the way fseek doesn't seek before the beginning of the file.....

which compiler do u use?????

Originally Posted by Salem

> i have run the code on tc2.0 it works fine...
You mean it worked "as you expected", and the implementation-defined behaviour worked in your favour.

That in no way means that every other implementation out there is going to do the same thing. Someone else's implementation-defined behaviour will see you "exit stage left" in no uncertain terms.

If you're using the standard API calls within the limits described by the standard, then a question like "which compiler" is meaningless as they all should be doing the same thing. That's not to say that compilers and libraries don't have bugs (they do), but the chances of you stumbling on one in such well-used areas is slim.

so you mean to say no code is perfect... i asked him which compiler because he was getting something wierd apart from the standard definition of fseek(); so it might be the fault of his compiler... i ve tried out several cases out of the reach....
so if you mean no code is perfect can you please do the favour of directing me how to test a code to prove it to be completely right?????

If you wanted to see if it conforms to some standard, then you would have to get a copy of that standard and compare it against it. Here are some links to some C standards:

http://cboard.cprogramming.com/showthread.php?t=84349

Pay special attention to "Annex J (informative) Portability issues".

SALEM and ZACS7 ... thankyou for the advice... surely portability would be an issue...
but can you guys see any problem with the code... if yes please suggest....

and SALEM your avatar says bye bye to void main...
well i read about the discussion but didnt get the point perfectly well...
can you explain or direct me...
awaiting your assistance...