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

 

[Arthur J. O'Dwyer]

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]

(e-mail address removed) (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.

 

[RCollins]

(e-mail address removed) (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.

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.

 

[CBFalconer]

(e-mail address removed) (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.

 

[Keith Thompson]

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.

 

[SM Ryan]

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

 

[RCollins]

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

 

[RCollins]

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

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.

 

[Keith Thompson]

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

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.

 

[SM Ryan]

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

 

[Mark McIntyre]

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

 

[Keith Thompson]

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

 

[RCollins]

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

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

 

[SM Ryan]

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

 

[CBFalconer]

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

 

[RCollins]

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

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

 

[Keith Thompson]

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