File seek

[SM Ryan]

#
#
# SM Ryan wrote:
#
# > #
# > #
# > # SM Ryan wrote:
# > #
# > # > # > # [...]
# > # > # > # > No, at the C source-code level, all files are just an un-differentiated
# > # > # > # > list of bytes. If the OS stores files as files of fixed record types
# > # > # > # > (such as VAX/VMS), then it is up to the implementation to "hide" these
# > # > # > # > messy details from the programmer.
# > # > # > #
# > # > # > # For purposes of C stdio, yes. In addition, the OS can (and does)
# > # > # > # provide system-specific interfaces that expose all the fixd record
# > # > # > # stuff to the programmer.
# > # > # >
# > # > # > I didn't realise fgetpos and ftell had been redefined so they no longer
# > # > # > can return a cookie that is system dependent, but now always return a
# > # > # > byte offset. I bet that really cheesed off the VMS people.
# > # > #
# > # > # The fpos_t value used by fgetpos and ftell may contain arbitrary
# > # > # system-specific information, but as far as I know it can't be used to
# > # > # get at VMS's record-oriented file interface.
# > # >
# > # > Why don't you and RCollins get together and come up with a consistent
# > # > answer.
# > # >
# > # > --
# > # > SM Ryan http://www.rawbw.com/~wyrmwif/
# > # > A bunch of savages in this town.
# > #
# > # <OT rambling about VAX/VMS>
# > # What was inconsistent? The C compiler hides the (very) ugly details
# > # of the VAX/VMS record system. Thank (deity of your choice) for that!
# > # </OT>
# >
# > So are you saying fgetpos and ftell always return a byte offset into the
# > file and never a system dependent cookie? Keith doesn't agree with you.
# > Who am I to believe?

# I haven't the foggiest idea what fgetpos returns in it's value.
# I don't care. I get a file position from fgetpos, and later I pass that
# value back to fsetpos to get back to the same place in the file. If
# there is system dependant data in there, then the compiler successfully
# hid it from me.

Okay. So the weird thing to me is that I started off saying that you can't
just fseek some byte offset on any operating system, but that what
you specify in fseek depends on the system, file organisation, etc. But
someone else pops and says, no, at the C source-code level, all files are
just an un-differentiated list of bytes. So are you saying I was correct
originally and the guy who popped off was just being a jackass. Or what?

 

[Keith Thompson]

# I haven't the foggiest idea what fgetpos returns in it's value.
# I don't care. I get a file position from fgetpos, and later I pass that
# value back to fsetpos to get back to the same place in the file. If
# there is system dependant data in there, then the compiler successfully
# hid it from me.

Okay. So the weird thing to me is that I started off saying that you can't
just fseek some byte offset on any operating system, but that what
you specify in fseek depends on the system, file organisation, etc. But
someone else pops and says, no, at the C source-code level, all files are
just an un-differentiated list of bytes. So are you saying I was correct
originally and the guy who popped off was just being a jackass. Or what?

I've directed followups to comp.lang.c; this isn't particularly
relevant to C++.

Please stop using '#' to delimit quotations, and start using "-- "
(the trailing blank is mandatory) to delimit your signature.

Nobody other than you is being a jackass. That was carefully phrased,
and is not intended to imply that you're a jackass yourself, merely to
refute your implication that somebody else (I'm not sure who) is being
a jackass.

Did you intend to change the subject from fgetpos/fsetpos to
ftell/fseek?

ftell and fseek use long int values to represent file positions. For
binary files, these values indicate byte offsets. For text files, it
may not be so simple; the only values you can safely pass to fseek are
zero and values previously returned by ftell for the same stream.

fgetpos and fsetpos use fpos_t values to represent a combination of a
file position and a parse state. The internal representation of an
fpos_t value is not defined by the language; it may or may not include
a simple byte offset. It just has to be implemented in such a way
that an fpos_t value returned by fgetpos can be used in a subsequent
call to fsetpos.

Any record structure implemented by the operating system may or may
not be reflected in the represention of fpos_t, but it can't be used
by any portable C program.

See any decent C text book, or the standard, for more information.

 

[Flash Gordon]

#
#
# SM Ryan wrote:
#
# > RCollins <[email protected]> wrote:

# > # <OT rambling about VAX/VMS>
# > # What was inconsistent? The C compiler hides the (very) ugly
# > # details of the VAX/VMS record system. Thank (deity of your
# > # choice) for that!</OT>
# >
# > So are you saying fgetpos and ftell always return a byte offset
# > into the file and never a system dependent cookie? Keith doesn't
# > agree with you. Who am I to believe?

# I haven't the foggiest idea what fgetpos returns in it's value.
# I don't care. I get a file position from fgetpos, and later I pass
# that value back to fsetpos to get back to the same place in the
# file. If there is system dependant data in there, then the compiler
# successfully hid it from me.

Okay. So the weird thing to me is that I started off saying that you
can't just fseek some byte offset on any operating system, but that
what you specify in fseek depends on the system, file organisation,
etc. But someone else pops and says, no, at the C source-code level,
all files are just an un-differentiated list of bytes. So are you
saying I was correct originally and the guy who popped off was just
being a jackass. Or what?

Nothing that you are allowed to know about makes it look like anything
other than a stream of bytes. The fact that you are not allowed to look
at the value returned by fgetpos means that you can't tell that it might
be record number + offset or something even stranger. It is hidden
because you are not told what it is and you are not allowed to do
anything with the value apart from pass it to fsetpos.

fseek, on the other hand, takes an offset in bytes which you do play
with yourself and and strangeness of the file system is again hidden
from you.

 

[RCollins]

#
#
# SM Ryan wrote:
#
# > #
# > #
# > # SM Ryan wrote:

Okay. So the weird thing to me is that I started off saying that you can't
just fseek some byte offset on any operating system, but that what
you specify in fseek depends on the system, file organisation, etc. But
someone else pops and says, no, at the C source-code level, all files are
just an un-differentiated list of bytes. So are you saying I was correct
originally and the guy who popped off was just being a jackass. Or what?

I think Keith and Flash summed it up pretty nicely. Use ftell/fseek
if you want to use a byte offset into a file; use fgetpos/fsetpos if
you just want to remember a specific location in a file.

As for the jackass part ... I don't remember exactly who it was, but
it might of been me. I *am* sometimes a jackass -- but not
intentionally. Honestly, I don't see why some people (ex-wives in
particular) take offsense just because somebody calls them a
bone-headed slack-jawed idiot

 

[Old Wolf]

fseek, on the other hand, takes an offset in bytes which you do play
with yourself and and strangeness of the file system is again hidden
from you.

Excellent thinly-veiled insult Perhaps he uses his non-standard
quote marker as an aide.

 

[Flash Gordon]

On 12 Aug 2004 14:23:19 -0700

Excellent thinly-veiled insult

Entirely unintended.

Perhaps he uses his non-standard
quote marker as an aide.

Yes, I agree that # as a quote marker is a real pain on a C news group.
If I set it as a quote marker it would make reading C source code
harder. If I don't it screws up the automatic wrapping etc.

 

[SM Ryan]

# Nothing that you are allowed to know about makes it look like anything
# other than a stream of bytes. The fact that you are not allowed to look

Actually, nothing that you are allowed to know about makes it looks like
anything at all except what you extract from the stream based on the
return of functions. Anything else is implementation dependent. And
off topic.

# fseek, on the other hand, takes an offset in bytes which you do play
# with yourself and and strangeness of the file system is again hidden
# from you.

See this is kind of thing that confuses me. I have experts like you
tell me this, but then I read things like

[#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.

So was I wrong to say that this things are implementation dependent
or am I just dealing with another jackass?

 

[Flash Gordon]

# Nothing that you are allowed to know about makes it look like
# anything other than a stream of bytes. The fact that you are not
# allowed to look

Actually, nothing that you are allowed to know about makes it looks
like anything at all except what you extract from the stream based on
the return of functions. Anything else is implementation dependent.
And off topic.

I failed to allow for text files. Since I have never claimed to be
perfect I am allowed to make mistakes or overlook things.

In this instance I will defer to Kieth on the values you can pass to
fseek when using a text file. However, the storage method of lines be it
CR/LF, LF/CR, CR, LF, variable record sizes, 0 padded fixed length
records or something stranger is still hidden from the C coder unless
they break the rules of C. Reading the text file as a text file byte by
byte you will see it as a stream of bytes with a single byte indicating
a new line whatever storage method is used.

# fseek, on the other hand, takes an offset in bytes which you do play
# with yourself and and strangeness of the file system is again hidden
# from you.

See this is kind of thing that confuses me. I have experts like you
tell me this, but then I read things like

[#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.

So was I wrong to say that this things are implementation dependent
or am I just dealing with another jackass?

If you pass something other than one of the allowed values to fseek on a
text stream then you are leaving the realms of C. If you stick to the
allowed methods of accessing files then all the implementation dependant
detail is hidden from you.

 

[Mark McIntyre]

So was I wrong to say that this things are implementation dependent
or am I just dealing with another jackass?

Ok, thats one Jackass too many. You're a rude idiot, and are herewith
plonked.

 

[SM Ryan]

# I failed to allow for text files. Since I have never claimed to be
# perfect I am allowed to make mistakes or overlook things.

Perhaps you should avoid condenscending and snide remarks when
responding to someone who did allow for text files.

 

[Keith Thompson]

# I failed to allow for text files. Since I have never claimed to be
# perfect I am allowed to make mistakes or overlook things.

Perhaps you should avoid condenscending and snide remarks when
responding to someone who did allow for text files.

Perhaps you should avoid condenscending and snide remarks altogether.

 

[CBFalconer]

# I failed to allow for text files. Since I have never claimed to
# be perfect I am allowed to make mistakes or overlook things.

Perhaps you should avoid condenscending and snide remarks when
responding to someone who did allow for text files.

PLONK for refusal to cooperate with existing standards or even to
present any excuse. I suggest others do likewise.