File seek

[Arvind Varma Kalidindi]

Hi,
I was asked this question in an interview recently. "How do you
move to the 6th byte in a file?" ... My thinking would be to find the
data types in the file, set a base pointer and advance it by 6. I
mean, ptr+6. Another way to ask the same question is how do you move
to the 3rd record in a file (considering that the file is made up of
records).
I told the interviewer that we could do a seek to move to the
specific byte. At that time, the interviewer nodded his head to show
his approval of my answer, but I came to know that he thought there is
a more effective way of doing this. Can anyone throw some pointers on
what that effective way could be?

Regards,
Arvind.

[Mauricio Lange]

Hi,
To move to the 6th byte you dont need to find the data types in the file. A
byte is a byte. Maybe he refered to that.

Mauricio

"Arvind Varma Kalidindi" <ax*****@lycos.com> wrote in message
news:26**************************@posting.google.c om...

Hi,
I was asked this question in an interview recently. "How do you
move to the 6th byte in a file?" ... My thinking would be to find the
data types in the file, set a base pointer and advance it by 6. I
mean, ptr+6. Another way to ask the same question is how do you move
to the 3rd record in a file (considering that the file is made up of
records).
I told the interviewer that we could do a seek to move to the
specific byte. At that time, the interviewer nodded his head to show
his approval of my answer, but I came to know that he thought there is
a more effective way of doing this. Can anyone throw some pointers on
what that effective way could be?

Regards,
Arvind.

[Arthur J. O'Dwyer]

On Tue, 10 Aug 2004, Arvind Varma Kalidindi wrote in comp.lang.c:

I was asked this question in an interview recently. "How do you
move to the 6th byte in a file?" ... My thinking would be to find the
data types in the file, set a base pointer and advance it by 6.
This is not coherent English. Files don't have "data types," and
you can't set C or C++ pointers to point /into/ files. You have to
read out the data first.
I mean, ptr+6. Another way to ask the same question is how do you move
to the 3rd record in a file (considering that the file is made up of
records).
And assuming that the first two records in the file have a total of
6 bytes between them, yes. :)
I told the interviewer that we could do a seek to move to the
specific byte. At that time, the interviewer nodded his head to show
his approval of my answer, but I came to know that he thought there is
a more effective way of doing this. Can anyone throw some pointers on
what that effective way could be?

I doubt he thought there was a more /effective/ way. You could
have been more /detailed/ in your answer, though; he might have
expected an interview candidate in C to be able to write down

fseek(fp, 6, SEEK_SET);

from memory (although I personally have to look up the order of
those parameters every time), and perhaps to explain why

if (fseek(fp, 6, SEEK_SET)) {
puts("I/O error during fseek");
}

would be more appropriate. He might have expected you to
recall that 'fseek' does not have well-defined behavior on text
streams except in very specific circumstances---consider the
definition of "the 6th byte" with respect to the text file

apple
banana
EOF

Is "the 6th byte" an ASCII newline, a carriage return, the letter 'b',
or what? A complete answer must at least explain the problem; and
the interviewer might then follow up with, "What is the best
interpretation in your opinion, and how would you implement it?"
leading to

for (i=0; i < 6; ++i) getc(fp);

The interviewer might even have wondered if you'd realize that
'fseek(fp, 6, SEEK_SET)' does /not/ retrieve the sixth byte in
a binary file at all, but rather the /seventh/ byte, because
'fseek' counts from zero. (It took me a while, too.)

And of course there are a whole slew of other answers in C++.
Don't crosspost between groups for different languages like this;
it just confuses people, and half the answers you get will be
unusable.

-Arthur

[SM Ryan]

ax*****@lycos.com (Arvind Varma Kalidindi) wrote:
# Hi,
# I was asked this question in an interview recently. "How do you
# move to the 6th byte in a file?" ... My thinking would be to find the
# data types in the file, set a base pointer and advance it by 6. I
# mean, ptr+6. Another way to ask the same question is how do you move
# to the 3rd record in a file (considering that the file is made up of
# records).

Something here is garbled or missing. There are many different ways of
encoding records in a file, and of indexing (or not indexing) a file's
record. Without information about file and record formats and indexing,
there's no real answer.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.

[RCollins]

SM Ryan wrote:

ax*****@lycos.com (Arvind Varma Kalidindi) wrote:
# Hi,
# I was asked this question in an interview recently. "How do you
# move to the 6th byte in a file?" ... My thinking would be to find the
# data types in the file, set a base pointer and advance it by 6. I
# mean, ptr+6. Another way to ask the same question is how do you move
# to the 3rd record in a file (considering that the file is made up of
# records).

Something here is garbled or missing. There are many different ways of
encoding records in a file, and of indexing (or not indexing) a file's
record. Without information about file and record formats and indexing,
there's no real answer.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.

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.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[CBFalconer]

SM Ryan wrote:

ax*****@lycos.com (Arvind Varma Kalidindi) wrote:

# I was asked this question in an interview recently. "How do you
# find the move to the 6th byte in a file?" ... My thinking would
# be to data types in the file, set a base pointer and advance it
# by 6. I mean, ptr+6. Another way to ask the same question is how
# do you move to the 3rd record in a file (considering that the
# file is made up of records).

Something here is garbled or missing. There are many different
ways of encoding records in a file, and of indexing (or not
indexing) a file's record. Without information about file and
record formats and indexing, there's no real answer.

Please don't use a non-standard quote marker (your #). It fouls
up reformatting software.

Answering the first sentence in the OPs article: Just read the
first 6 bytes of the newly opened stream with fread(). Discard
them. You are positioned.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"A man who is right every time is not likely to do very much."
- Francis Crick, co-discover of DNA

[Keith Thompson]

RCollins <rc***@nospam.theriver.com> writes:
[...]

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.

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

[SM Ryan]

Keith Thompson <ks***@mib.org> wrote:
# RCollins <rc***@nospam.theriver.com> writes:
# [...]
# > 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.

[RCollins]

Keith Thompson wrote:

RCollins <rc***@nospam.theriver.com> writes:
[...]

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.

Non-standard stuff. Do we care about that in c.l.c. ?

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[RCollins]

SM Ryan wrote:

Keith Thompson <ks***@mib.org> wrote:
# RCollins <rc***@nospam.theriver.com> writes:
# [...]
# > 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.

Actually, it really made life easier (at least, in my group). VMS
provides about a ga-zillion different record formats, and we were
writing specific code for each format (when using FORTRAN). With the
more simplistic <stdio> stuff, all we had to do was parse our data
from a single input format.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Keith Thompson]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

Keith Thompson <ks***@mib.org> wrote:
# RCollins <rc***@nospam.theriver.com> writes:
# [...]
# > 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.

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

[Keith Thompson]

RCollins <rc***@nospam.theriver.com> writes:

Keith Thompson wrote:

RCollins <rc***@nospam.theriver.com> writes:
[...]

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.

Non-standard stuff. Do we care about that in c.l.c. ?

Not about the details, but there's nothing off-topic about mentioning
that system-specific interfaces exist.

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

[SM Ryan]

Keith Thompson <ks***@mib.org> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# > Keith Thompson <ks***@mib.org> wrote:
# > # RCollins <rc***@nospam.theriver.com> writes:
# > # [...]
# > # > 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.

[Mark McIntyre]

On Wed, 11 Aug 2004 21:56:27 -0000, in comp.lang.c , SM Ryan
<wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Keith Thompson <ks***@mib.org> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# >
# > 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.

In fact the answers /were/ consistent, if you read them carefully.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Keith Thompson]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

Keith Thompson <ks***@mib.org> wrote:

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

Keith Thompson <ks***@mib.org> wrote:
> RCollins <rc***@nospam.theriver.com> writes:
> [...]
> > 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.

How were our answers inconsistent?

BTW, a couple of requests: First, please use '>', not '#', to denote
quoted text; using '#' confuses reformatters. Second, your signature
should be introduced by a line consisting of "-- "; yours is missing
the trailing blank, so it isn't being recognized as a signature.

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

[RCollins]

SM Ryan wrote:

Keith Thompson <ks***@mib.org> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# > Keith Thompson <ks***@mib.org> wrote:
# > # RCollins <rc***@nospam.theriver.com> writes:
# > # [...]
# > # > 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>

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[SM Ryan]

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan wrote:
#
# > Keith Thompson <ks***@mib.org> wrote:
# > # SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# > # > Keith Thompson <ks***@mib.org> wrote:
# > # > # RCollins <rc***@nospam.theriver.com> writes:
# > # > # [...]
# > # > # > 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?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
GERBILS
GERBILS
GERBILS

[CBFalconer]

SM Ryan wrote:

RCollins <rc***@nospam.theriver.com> wrote:
# .... snip ... #
# <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?

The people who ask you to cease and desist with the non-standard
quotation marker.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"A man who is right every time is not likely to do very much."
- Francis Crick, co-discover of DNA

[RCollins]

SM Ryan wrote:

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan wrote:
#
# > Keith Thompson <ks***@mib.org> wrote:
# > # SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# > # > Keith Thompson <ks***@mib.org> wrote:
# > # > # RCollins <rc***@nospam.theriver.com> writes:
# > # > # [...]
# > # > # > 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?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
GERBILS
GERBILS
GERBILS

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.

Note that this is true on *any* system, not just VAX/VMS. In fact, I
would assume that the 'value' returned by the fgetpos family of
functions is completely different on each OS type.

From the C89 standard (the only one I have handy at the moment):

<Q>
4.9.9.1 The fgetpos function

Synopsis

#include <stdio.h>
int fgetpos(FILE *stream, fpos_t *pos);

Description

The fgetpos function stores the current value of the file position
indicator for the stream pointed to by stream in the object pointed to
by pos . The value stored contains unspecified information usable by
^^^^^^^^^^^^^^^^^^^^^^^
the fsetpos function for repositioning the stream to its position at
the time of the call to the fgetpos function.
</Q>

Note the part I underlined. Also note, I *still* don't see the
inconsistancy you are talking about.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Keith Thompson]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

RCollins <rc***@nospam.theriver.com> 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?

Actually, I think RCollins are in complete agreement that you're
wrong.

RCollins said that the C compiler (and by implication fgetpos and
ftell) hides the details of the VAX/VMS record system. (Strictly
speaking it's the library, not the compiler, but that's a minor
point.) He said nothing about *how* it hides those details. fpos_t
is a system dependent cookie; one way to implement such a cookie is as
a byte offset.

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

[SM Ryan]

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan wrote:
#
# > RCollins <rc***@nospam.theriver.com> wrote:
# > #
# > #
# > # SM Ryan wrote:
# > #
# > # > Keith Thompson <ks***@mib.org> wrote:
# > # > # SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# > # > # > Keith Thompson <ks***@mib.org> wrote:
# > # > # > # RCollins <rc***@nospam.theriver.com> writes:
# > # > # > # [...]
# > # > # > # > 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?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Haven't you ever heard the customer is always right?

[Keith Thompson]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

RCollins <rc***@nospam.theriver.com> wrote: [...] # 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.

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

[Flash Gordon]

On Thu, 12 Aug 2004 07:24:30 -0000
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan wrote:
#
# > RCollins <rc***@nospam.theriver.com> wrote:
<snip>
# > # <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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[RCollins]

SM Ryan wrote:

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan wrote:
#
# > RCollins <rc***@nospam.theriver.com> wrote:
# > #
# > #
# > # SM Ryan wrote: <snip>

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?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Haven't you ever heard the customer is always right?

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 :)

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Old Wolf]

Flash Gordon <sp**@flash-gordon.me.uk> wrote"

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan 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?

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
ol*****@inspire.net.nz (Old Wolf) wrote:

Flash Gordon <sp**@flash-gordon.me.uk> wrote"

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

RCollins <rc***@nospam.theriver.com> wrote:
#
#
# SM Ryan 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?
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 :)

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[SM Ryan]

Flash Gordon <sp**@flash-gordon.me.uk> wrote:

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

--
SM Ryan http://www.rawbw.com/~wyrmwif/
JUSTICE!
Justice is dead.

[Flash Gordon]

On Fri, 13 Aug 2004 03:14:15 -0000
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Flash Gordon <sp**@flash-gordon.me.uk> wrote:

# 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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Mark McIntyre]

On Fri, 13 Aug 2004 03:14:15 -0000, in comp.lang.c , SM Ryan
<wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

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

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I have no respect for people with no shopping agenda.

[Keith Thompson]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

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

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

[CBFalconer]

SM Ryan wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!