File seek

**Mauricio Lange** · Jul 22 '05, 05:45 PM

Re: File seek

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" <axvarma@lycos. com> wrote in message
news:2614aa51.0 408101146.5f3ff 30b@posting.goo gle.com...[color=blue]
> 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.[/color]

**Arthur J. O'Dwyer** · Jul 22 '05, 05:46 PM

Re: File seek

On Tue, 10 Aug 2004, Arvind Varma Kalidindi wrote in comp.lang.c:[color=blue]
>
> 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.[/color]

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.
[color=blue]
> 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).[/color]

And assuming that the first two records in the file have a total of
6 bytes between them, yes. :)
[color=blue]
> 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?[/color]

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** · Jul 22 '05, 05:46 PM

Re: File seek

axvarma@lycos.c om (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** · Jul 22 '05, 05:46 PM

Re: File seek

SM Ryan wrote:[color=blue]
> axvarma@lycos.c om (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.[/color]

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** · Jul 22 '05, 05:46 PM

Re: File seek

SM Ryan wrote:[color=blue]
> axvarma@lycos.c om (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.[/color]

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** · Jul 22 '05, 05:47 PM

Re: File seek

RCollins <rcoll@nospam.t heriver.com> writes:
[...][color=blue]
> 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.[/color]

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_Keit h) kst-u@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** · Jul 22 '05, 05:47 PM

Re: File seek

Keith Thompson <kst-u@mib.org> wrote:
# RCollins <rcoll@nospam.t heriver.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** · Jul 22 '05, 05:48 PM

Re: File seek

Keith Thompson wrote:[color=blue]
> RCollins <rcoll@nospam.t heriver.com> writes:
> [...]
>[color=green]
>>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.[/color]
>
>
> For purposes of C stdio, yes. In addition, the OS can (and does)
> provide system-specific interfaces that expose all the fixd record[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^[color=blue]
> stuff to the programmer.
>[/color]

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** · Jul 22 '05, 05:48 PM

Re: File seek

SM Ryan wrote:
[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:
> # RCollins <rcoll@nospam.t heriver.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.[/color]

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** · Jul 22 '05, 05:48 PM

Re: File seek

SM Ryan <wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:
> # RCollins <rcoll@nospam.t heriver.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.[/color]

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_Keit h) kst-u@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** · Jul 22 '05, 05:48 PM

Re: File seek

RCollins <rcoll@nospam.t heriver.com> writes:[color=blue]
> Keith Thompson wrote:[color=green]
> > RCollins <rcoll@nospam.t heriver.com> writes:
> > [...]
> >[color=darkred]
> >>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.[/color]
> >
> >
> > For purposes of C stdio, yes. In addition, the OS can (and does)
> > provide system-specific interfaces that expose all the fixd record[/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^^^^[color=green]
> > stuff to the programmer.
> >[/color]
>
> Non-standard stuff. Do we care about that in c.l.c. ?[/color]

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

--
Keith Thompson (The_Other_Keit h) kst-u@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** · Jul 22 '05, 05:48 PM

Re: File seek

Keith Thompson <kst-u@mib.org> wrote:
# SM Ryan <wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:
# > Keith Thompson <kst-u@mib.org> wrote:
# > # RCollins <rcoll@nospam.t heriver.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** · Jul 22 '05, 05:48 PM

Re: File seek

On Wed, 11 Aug 2004 21:56:27 -0000, in comp.lang.c , SM Ryan
<wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> wrote:
[color=blue]
>Keith Thompson <kst-u@mib.org> wrote:
># SM Ryan <wyrmwif@tang o-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.[/color]

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** · Jul 22 '05, 05:49 PM

Re: File seek

SM Ryan <wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:[color=green]
> > SM Ryan <wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:[color=darkred]
> > > Keith Thompson <kst-u@mib.org> wrote:
> > > > RCollins <rcoll@nospam.t heriver.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.[/color]
> >
> > 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.[/color]
>
> Why don't you and RCollins get together and come up with a consistent
> answer.[/color]

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_Keit h) kst-u@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.

File seek

File seek

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment