By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,591 Members | 629 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,591 IT Pros & Developers. It's quick & easy.

textvsbinary

P: n/a
Hi all

http://www.c-faq.com/stdio/textvsbinary.html

it is written as follows

Furthermore, for analogous reasons, the fseek and ftell functions do
not necessarily deal in pure byte offsets from the beginning of the
file.

can anybody give examples/explanations for this ??

what exactly is this pure byte offset value ??

Does it mean that offset values are those which can be represented by
a string of 8 bits??

Apr 21 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
aa*****@gmail.com writes:
http://www.c-faq.com/stdio/textvsbinary.html

it is written as follows

Furthermore, for analogous reasons, the fseek and ftell functions do
not necessarily deal in pure byte offsets from the beginning of the
file.

can anybody give examples/explanations for this ??

what exactly is this pure byte offset value ??

Does it mean that offset values are those which can be represented by
a string of 8 bits??


No, it refers to an offset value that represents a simple count of
bytes, counted from the beginning of the file.

On some systems, all files are represented as sequences of bytes, with
no additional structure imposed by the operating system. On such a
system, the simplest way to represent a position within a file (the
value returned by ftell() and used by fseek() is just a count of the
number of bytes between the beginning of the file and the specified
position.

For text files, the way an end-of-line is represented in the file can
complicate things. For example, each end-of-line might be represented
as a 2-character sequence, but getchar() must still return a single
'\n' character when it reads this sequence. This means that the
number of bytes that have been read by getchar() might not be the same
as a simple byte offset from the beginning of the file.

Examples:

Unix-like systems use a single ASCII LF character to indicate the end
of a line, and there's no real difference in behavior between text
files and binary files. fseek() and ftell() use a simple count of
bytes to indicate a positoin within a file, either text or binary.

Windows systems use a pair of characters, ASCII CR followed by ASCII
LF, to indicate the end of a line. If you read such a file in binary
mode, you'll see the CR and the LF characters individually (as '\r'
and '\n'). If you read the file in text mode, you'll only see a
single '\n' character. I *think* that fseek and ftell still use a
simple count of bytes to represent an offset within a file, but this
count doesn't necessarily match the number of characters that can be
read from the file in text mode.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 21 '06 #2

P: n/a
aa*****@gmail.com wrote:
Hi all

http://www.c-faq.com/stdio/textvsbinary.html

it is written as follows

Furthermore, for analogous reasons, the fseek and ftell functions do
not necessarily deal in pure byte offsets from the beginning of the
file.

can anybody give examples/explanations for this ??
In DOS/Windows text files each end of line will be marked by 2
characters, CRLF, but when you read the file in text mode you will just
see a single newline character. So given the text file:
a
b
you actually have 6 characters, a, carriage return, new line, b,
carriage return, new line. When read in text mode you would see 4
characters, "a/nb/n". So the return values for ftell could be:
a = 0
first /n = 1
b = 3
first /n = 4
Or equally sensibly:
a = 0
first /n = 2
b = 3
first /n = 5
Neither of these corresponds to what you would expect when reading the file.

Alternatively, the system could do clever things to make it look as you
would expect (I seem to recall Jacob has opinions on this and knows of
implementations that do it) so you would get:
a = 0
first /n = 1
b = 2
first /n = 3

Obviously, whatever definition you use for "byte offset", either based
on the number of bytes you would have to read, or the number of bytes in
the real file, at *least* one of the above cannot be a simple byte offset.
what exactly is this pure byte offset value ??

Does it mean that offset values are those which can be represented by
a string of 8 bits??


No, it means the number of bytes you would have to read to get to that
position from the start of the file.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Apr 21 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.