Move the file pointer to the beginning of the file (text mode inWindows)?

[MBALOVER]

Hi all,

I have a text file opened using the function fopen(filename,'r').
Assume that after some file reading, the file pointer is at position
X. Now I want to move it to the beginning of the file.

I see function fsee() can help to move the file pointer to a position
in the file. Unfortunately according to my book, on MS DOS, it works
only with binary files. (in UNIX it works for both binary and text
files, though).

My program is written in Windows OS so I guess this function does not
work either.

Do you know in Windows, what function I can use to move the file
pointer to a specific position in my text file?

Thanks

 

[Seebs]

I see function fsee() can help to move the file pointer to a position
in the file. Unfortunately according to my book, on MS DOS, it works
only with binary files. (in UNIX it works for both binary and text
files, though).

My program is written in Windows OS so I guess this function does not
work either.

Do you know in Windows, what function I can use to move the file
pointer to a specific position in my text file?

This is arguably a Windows question. But!

1. You can use fseek with a value previously returned by ftell. So
if you call ftell at the start of your operation, you should be able to
seek back to that location.
2. rewind() should work, I believe.
3. fseek(stream, 0, SEEK_SET) should work even on text streams.
4. You probably need a better book.

-s

 

[Ersek, Laszlo]

Hi all,

I have a text file opened using the function fopen(filename,'r').
Assume that after some file reading, the file pointer is at position
X. Now I want to move it to the beginning of the file.
rewind()


I see function fsee() can help to move the file pointer to a position
in the file. Unfortunately according to my book, on MS DOS, it works
only with binary files. (in UNIX it works for both binary and text
files, though).

Seeking to offset 0 is much less generic than seeking to somewhere else,
so it will work. The C99 standard says,

----v----
The rewind function sets the file position indicator for the stream
pointed to by stream to the beginning of the file. It is equivalent to

(void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.
----^----

Do you know in Windows, what function I can use to move the file
pointer to a specific position in my text file?

This will always work:

1) open the file
2) read up to a point
3) fgetpos()
4) read on
5) fsetpos() back to the position stored in step 3.

lacos

 

[MBALOVER]

Thanks Seebs and Laszlo,

I will try these methods.

By the way, the book I mentioned is "A Book on C: Programming in C
(4th Edition)" by Kelley and Pohl.

I am not sure if this is a good book but my colleague, a experienced
software developer, recommended me this book.

Thanks

 

[Ben Pfaff]

Seeking to offset 0 is much less generic than seeking to somewhere else,
so it will work. The C99 standard says,

----v----
The rewind function sets the file position indicator for the stream
pointed to by stream to the beginning of the file. It is equivalent to

(void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.
----^----

More to the point:

7.19.9.2 The fseek function
Synopsis
1 #include <stdio.h>
int fseek(FILE *stream, long int offset, int whence);
Description
[...]
4 For a text stream, either offset shall be zero, or offset
shall be a value returned by an earlier successful call to
the ftell function on a stream associated with the same file
and whence shall be SEEK_SET.

In other words, an offset of zero is explicitly allowed for a
text stream.

 

[Seebs]

I will try these methods.

By the way, the book I mentioned is "A Book on C: Programming in C
(4th Edition)" by Kelley and Pohl.

I am not sure if this is a good book but my colleague, a experienced
software developer, recommended me this book.

Huh. I've heard good things about Kelley & Pohl before. Haven't read it
myself, though.

-s

 

[MBALOVER]

Thanks a lot.

But I am still confused because what I found in the Kelley and Pohl's
book:

"The function fseek() and ftell() are guaranteed to work properly only
on binary files. In MS-DOS, if we want to use these functions, the
file should be opened with a binary mode."

It would be great if everything is explained clearly. Why does the
book say that? is it obsolete?

Thanks

Seeking to offset 0 is much less generic than seeking to somewhere else,
so it will work. The C99 standard says,

----v----
The rewind function sets the file position indicator for the stream
pointed to by stream to the beginning of the file. It is equivalent to

        (void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.
----^----

More to the point:

     7.19.9.2 The fseek function
     Synopsis
1           #include <stdio.h>
            int fseek(FILE *stream, long int offset, int whence);
     Description
[...]
4    For a text stream, either offset shall be zero, or offset
     shall be a value returned by an earlier successful call to
     the ftell function on a stream associated with the same file
     and whence shall be SEEK_SET.

In other words, an offset of zero is explicitly allowed for a
text stream.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

 

[Seebs]

But I am still confused because what I found in the Kelley and Pohl's
book:

"The function fseek() and ftell() are guaranteed to work properly only
on binary files. In MS-DOS, if we want to use these functions, the
file should be opened with a binary mode."

It would be great if everything is explained clearly. Why does the
book say that? is it obsolete?

That sounds like a plain error. However, since the behavior of fseek()
and ftell() is a bit weird on text files, I could easily imagine someone
getting the impression that they just don't work there. Still, either
it's a plain error, or MS-DOS compilers and libraries were crap.
(Note that Windows is not actually MS-DOS, although they have some
similarities.)

The basic issue, as it would apply to DOS, is this: Imagine that you are
reading a text file. Somewhere in there, there will be a \r\n sequence,
perhaps.

If you call getc() while the stream is pointing at the \r, it'll consume
both characters and return a \n, in text mode. Now what happens if, after
that, you seek back a single character? It's not a valid state for the
stream. There's no such thing as a bare newline in a proper text file.

So in general, it's not defined to seek to arbitrary locations -- but it is
defined to seek to zero, or to a value returned by ftell().

-s

 

[MBALOVER]

That sounds like a plain error.  However, since the behavior of fseek()
and ftell() is a bit weird on text files, I could easily imagine someone
getting the impression that they just don't work there.  Still, either
it's a plain error, or MS-DOS compilers and libraries were crap.
(Note that Windows is not actually MS-DOS, although they have some
similarities.)

The basic issue, as it would apply to DOS, is this:  Imagine that you are
reading a text file.  Somewhere in there, there will be a \r\n sequence,
perhaps.

If you call getc() while the stream is pointing at the \r, it'll consume
both characters and return a \n, in text mode.  Now what happens if, after
that, you seek back a single character?  It's not a valid state for the
stream.  There's no such thing as a bare newline in a proper text file.

So in general, it's not defined to seek to arbitrary locations -- but it is
defined to seek to zero, or to a value returned by ftell().

Hi Seebs,

Your explanation is clear and makes sense to me.

Thanks a lot.

Best,

 

[Richard Bos]

That sounds like a plain error. However, since the behavior of fseek()
and ftell() is a bit weird on text files, I could easily imagine someone
getting the impression that they just don't work there. Still, either
it's a plain error, or MS-DOS compilers and libraries were crap.

I still have a book on Turbo C lying about, and it does mention 0 for
text files. So it's an error in K&P.

Richard