Re: [Mingw-users] Re: fseek with SEEK_SET

[Oscar F. <of...@wa...>]

Benjamin Riefenstahl <Ben...@ep...> writes:

>> ml...@mu... writes:
>>> when fseek is called, for example, like this:
>>>
>>> file_pointer=fopen(filename,"ab");
>>> fseek(file_pointer,4,SEEK_SET);
>>>
>>> it actually seeks to the end of the file instead of the 4th byte.
>>> Is this a known problem under Windows ?
>
> Oscar Fuentes <of...@wa...> writes:
>> A look at the C standard should clarify things, but it's too late
>> here.
>
> If I may, C89 says:
>
>   Opening a file with append mode ('a' [...]) causes all subsequent
>   writes to the file to be forced to the then current end-of-file,
>   regardless of intervening calls to the fseek function.

Thanks for looking up this, Benny.

> It doesn't seem to mention how ftell() is supposed to behave, but I
> guess that just ignoring fseek() on such a stream is reasonable.
>
> Things get more interesting with "a+b", because that should allow
> reading at any place in the file, so with such a stream fseek() can
> not be a no-op.

Indeed, a fseek, fsetpos or rewind is *required* when you want to read
after a write, or vice-versa. For the specific case of output, you can
use fflush instead, unless you encounter end-of-file. On that last
case no function needs to be called before the output. For every write
operation the implementation positions the file pointer at the end of
the file.

-- 
Oscar