Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #53896

Re: fseek(), offset and ftell()

Show all headers | View raw

arnuld <sunrise@invalid.address> writes:
> There are several contradicting definitions of the behavior of fseek() . 
> I do not know mhich one to believe:

There is no real contradiction.

>> n1570.pdf: 
>> section 7.21.9.2 
>
>> int fseek(FILE *stream, long int offset, int whence);
>
>> For a binary stream, the new position, measured in characters from the 
>> beginning of the file, is obtained by adding offset to the position 
>> specified by whence. The specified position is the beginning of the 
>> file if whence is SEEK_SET, the current value of the file position 
>> indicator if SEEK_CUR, or end-of-file if SEEK_END. A binary stream need
>> not meaningfully support fseek calls with a whence value of SEEK_END.
>
> I have used seek on a text file (I assume a file containing C code as 
> text qualifies as a text stream) and I see new position is measured in 
> characters there too. Then why standard mentioned only binary streams ?
>
>> 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.
>
> Standard says value should be eitehr zero or a returned value from
> ftell() which returns only current position.  Now if I want to go past 
> the 100 characters and start reading from 101st character onwards, how to 
> do that ?  In gcc simply putting 100 or 101 or 9 works, you can seek to 
> any character by just putting it as 2nd argument to fseek() but is that 
> correct way ? 

On a UNIX-like system, a text file is a sequence of lines, where each
line is a sequence of characters terminated by a '\n' character.  You
can read the same file in text or binary mode and get exactly the same
byte sequence.

That's not true on all systems, and the standard doesn't require it.

The standard only specifies the behavior that's guaranteed for *all*
conforming implementations.

    A binary stream need not meaningfully support fseek calls with a
    whence value of SEEK_END.

Some systems might store binary files as a whole number of fixed-length
blocks, with no information about how many bytes are in the final block.
On such a system, fseek with SEEK_END might go to the end of the last
block, even if not that many bytes have been written.  On a UNIX-like
system, a binary file is stored as an arbitrary sequence of bytes, and
fseek with SEEK_END works perfectly well.  Code that relies on this will
not be portable to non-UNIX systems.

    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.

This is a Standardese use of the word "shall".  If the word "shall"
appears in the Standard outside a constraint, as it does here, it
doesn't mean that something is either required or forbidden; it means
that any program that violates it has undefined behavior (which merely
means behavior that is not defined *by the C standard*).

If you fseek() to position 100 in a text file on a UNIX-file system, it
will do exactly what you expect.  The above quoted paragraph merely
means that the C standard doesn't guarantee that behavior.

Some examples:

On Windows, end-of-line is represented by a 2-character sequence "\r\n".
Reading an end-of-line from a text file on Windows returns a single '\n'
character, but fseek works on the number of bytes *in the physical
file*, not the number of characters you'll get if you read from it.  You
can specify a position in a text file by reading to that position and
then calling ftell(); that method will work on any conforming C
implementation.

On other systems, text files might be stored as fixed-length records.
Reading from such a file in text mode will convert that format to
sequences of characters terminated by '\n'; seeking to arbitary
positions won't do what you expect, and might not even be permitted.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

fseek(), offset and ftell() arnuld <sunrise@invalid.address> - 2014-12-04 08:42 +0000
  Re: fseek(), offset and ftell() Robert Wessel <robertwessel2@yahoo.com> - 2014-12-04 03:28 -0600
  Re: fseek(), offset and ftell() James Kuyper <jameskuyper@verizon.net> - 2014-12-04 11:25 -0500
    Re: fseek(), offset and ftell() glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-04 16:49 +0000
  Re: fseek(), offset and ftell() Keith Thompson <kst-u@mib.org> - 2014-12-04 09:05 -0800
    Re: fseek(), offset and ftell() "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-04 14:13 -0500
      Re: fseek(), offset and ftell() "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-04 16:01 -0500
    Re: fseek(), offset and ftell() glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-04 21:42 +0000
      Re: fseek(), offset and ftell() Nobody <nobody@nowhere.invalid> - 2014-12-05 00:24 +0000
        Re: fseek(), offset and ftell() "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-04 21:29 -0500

csiph-web