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

Groups > comp.lang.c > #53892

Re: fseek(), offset and ftell()

Show all headers | View raw

On 12/04/2014 03:42 AM, arnuld wrote:
> There are several contradicting definitions of the behavior of fseek() .

What are the contradictory definitions? Unless I've misread your
message, you only provide one definition below, and I didn't notice any
internal contradictions. What contradictions have you seen between the
definitions you're referring to?

> I do not know mhich one to believe:
> 
>> 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 ?

Because there are many different ways a text stream can indicate the end
of a line, and correspondingly many different ways of implementing
fseek() on text streams. Examples of schemes that I've heard about:
1. A single new-line character - which can be different on different
systems.
2. A pair of characters that together indicate end-of-line - the pairing
can be different on different systems.
3. Files organized in blocks, with end-of-line within a block indicated
by having the rest of the block filled in with padding. On some systems,
the padding character is '\0', but on others it's a blank - which is why
the standard explicitly permits the number of blank characters at the
end of a line be different when it is read from a text stream than it
was when the line was written.
4. Files organized in blocks, with end-of-line indicated by a byte at
the beginning of the block saying how much of the block is actually
used. The remaining bytes of the block might be either padded or filled
with garbage.

So - how would you like the offset to work when it crosses the end of a
line? Should it increase by only 1, regardless of how end-of-line is
indicated? Should it increase by 2 if the two characters are used to
indicate end-of-line? Should it include or exclude padding/garbage at
the end of a block? Each way of doing things has it's advantages and
disadvantages, and different systems make different choices. The
committee chose to define text mode for the specific purpose of allowing
such variations. If such variations weren't allowed, binary mode would
not need to be distinct from text mode.

>> 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 ?

Violating a "shall" that occurs outside of a constraint section means
that the behavior is undefined - which is standardese with simply means
that the standard itself does not define the behavior - the
implementation is free to provide it's own definition. On Unix-like
systems, text mode behaves exactly the same as binary mode, so what
you're saying should work fine. You'll have to read the documentation
for other systems to find out what works there. Since the behavior is
undefined, rather than implementation-defined, a conforming
implementation of C need not provide such documentation, but any
reasonable implementation of C will document it.

For portable code working on a text stream, replace calls to fseek()
which would violate those shalls with calls to functions which read the
the appropriate number of characters, which you can then discard
unprocessed. This will result in newlines always being treated as 1
character long, regardless of the actual method used to indicate
end-of-line.

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