Increment file pointer

[deepak]

hi folks

I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

Thanks in advance
Deepak garg

[Joona I Palaste]

deepak <de*********@rediffmail.com> scribbled the following:

hi folks I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

It's undefined.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield

[Richard Heathfield]

deepak wrote:

hi folks

I have a pointer to a file. If i increment the pointer, where will it
point. I could not find the problem in the FAQs.

It's FAQ 4.4, which doesn't appear to be in the online version. In that
answer, Steve Summit says that "pointer arithmetic in C is always
automatically scaled by the size of the objects pointed to", which is a
very good way to put it.

It is easy to make the mistake of thinking that a so-called "file pointer"
points to a position in the file, so that incrementing it would make it
point to the next position, but such thinking is flawed. A file pointer
points to a FILE object, and it is the FILE object contains information
about the stream being read, written or updated, such as (for example) a
current position indicator.

++fp; is normally asking for trouble. I can think of circumstances where it
might be useful, but they are not overly common.

Example of incrementing fp:

FILE OutputArray[12 + 1] = {0};
FILE *fp = NULL;

if(OK == OpenAllMyFiles(OutputArray,
sizeof OutputArray / sizeof OutputArray[0]) - 1)
{
for(fp = OutputArray; fp != NULL; fp++)
{
DoSomethingWith(data, fp);
}
}

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Christian Bau]

In article <7c**************************@posting.google.com >,
de*********@rediffmail.com (deepak) wrote:

hi folks

I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

Past the end of the file.

[Joona I Palaste]

Christian Bau <ch***********@cbau.freeserve.co.uk> scribbled the following:

In article <7c**************************@posting.google.com >,
de*********@rediffmail.com (deepak) wrote:

hi folks

I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

Past the end of the file.

Sorry, no. It might not even point at a valid FILE object at all.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon

[Christian Bau]

In article <bm**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Christian Bau <ch***********@cbau.freeserve.co.uk> scribbled the following:

In article <7c**************************@posting.google.com >,
de*********@rediffmail.com (deepak) wrote:

hi folks

I have a pointer to a file. If i increment the pointer, where will it
point.
I could not find the problem in the FAQs.

Past the end of the file.

Sorry, no. It might not even point at a valid FILE object at all.

It might not point to a valid "file" (whatever that is, concluding that
he meant a FILE object is pure guessing), but it definitely points past
the end of the file that the original pointer pointed to.

[Dan Pop]

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:

hi folks

I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.
The operation is perfectly OK, as long as you don't try to dereference
the result (or pass it to some function expecting a valid FILE pointer).

The following code has well defined behaviour:

FILE *mystdout == stdin;
mystdout++;
fprintf(--mystdout, "hello world\n");

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <bm**********@sunnews.cern.ch> I wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:

hi folks

I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.
The operation is perfectly OK, as long as you don't try to dereference
the result (or pass it to some function expecting a valid FILE pointer).

The following code has well defined behaviour:

Especially after applying the following patch ;-)
FILE *mystdout == stdin;
s/stdin/stdout
mystdout++;
fprintf(--mystdout, "hello world\n");

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joe Wright]

Dan Pop wrote:

In <bm**********@sunnews.cern.ch> I wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:
hi folks

I have a pointer to a file. If i increment the pointer, where will it point.
I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.
The operation is perfectly OK, as long as you don't try to dereference
the result (or pass it to some function expecting a valid FILE pointer).

The following code has well defined behaviour:

Especially after applying the following patch ;-)

FILE *mystdout == stdin;

s/stdin/stdout

mystdout++;
fprintf(--mystdout, "hello world\n");

I'd thought you'd have changed '==' to '=' as well.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Micah Cowan]

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <bm**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Christian Bau <ch***********@cbau.freeserve.co.uk> scribbled the following:

In article <7c**************************@posting.google.com >,
de*********@rediffmail.com (deepak) wrote:
> hi folks
>
> I have a pointer to a file. If i increment the pointer, where will it
> point.
> I could not find the problem in the FAQs.

Past the end of the file.

Sorry, no. It might not even point at a valid FILE object at all.

It might not point to a valid "file" (whatever that is, concluding that
he meant a FILE object is pure guessing), but it definitely points past
the end of the file that the original pointer pointed to.

To be slightly more accurate, it will point past the end of the
FILE object.

-Micah

[Richard Heathfield]

Dan Pop wrote:

In <bm**********@sunnews.cern.ch> I wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:
hi folks

I have a pointer to a file. If i increment the pointer, where will it
point. I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.
The operation is perfectly OK, as long as you don't try to dereference
the result (or pass it to some function expecting a valid FILE pointer).

The following code has well defined behaviour:

Especially after applying the following patch ;-)

FILE *mystdout == stdin;

s/stdin/stdout

....and the following following patch...

s/==/=/

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Joona I Palaste]

Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:

Dan Pop wrote:

In <bm**********@sunnews.cern.ch> I wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:
deepak <de*********@rediffmail.com> scribbled the following:
> hi folks

> I have a pointer to a file. If i increment the pointer, where will it
> point. I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.
The operation is perfectly OK, as long as you don't try to dereference
the result (or pass it to some function expecting a valid FILE pointer).

The following code has well defined behaviour:
Especially after applying the following patch ;-)

FILE *mystdout == stdin;

s/stdin/stdout

...and the following following patch... s/==/=/

Dang, Dan Pop made a mistake in *two* consecutive posts and I missed the
opportunity to gloat over it. =)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola

[Richard Heathfield]

Joona I Palaste wrote:

Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following:

Dan Pop wrote:

In <bm**********@sunnews.cern.ch> I wrote:
In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:
>deepak <de*********@rediffmail.com> scribbled the following:
>> hi folks
>
>> I have a pointer to a file. If i increment the pointer, where will it
>> point. I could not find the problem in the FAQs.
>
>It's undefined.

It's perfectly well defined: one byte after the current FILE object.
The operation is perfectly OK, as long as you don't try to dereference
the result (or pass it to some function expecting a valid FILE pointer).

The following code has well defined behaviour:

Especially after applying the following patch ;-)

FILE *mystdout == stdin;

s/stdin/stdout

...and the following following patch...

s/==/=/

Dang, Dan Pop made a mistake in *two* consecutive posts and I missed the
opportunity to gloat over it. =)

The Curse of Google Groups...

"many (most) programmers prefer to be _very_ careful when they type the
equality operator rather than compromise the readability of their code,
especially for the people who will have to maintain it later." - Dan Pop, 1
May 1995

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

Micah Cowan wrote:

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <bm**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

> Christian Bau <ch***********@cbau.freeserve.co.uk> scribbled the
> following:
> > In article <7c**************************@posting.google.com >,
> > de*********@rediffmail.com (deepak) wrote:
> >> hi folks
> >>
> >> I have a pointer to a file. If i increment the pointer, where will
> >> it point.
> >> I could not find the problem in the FAQs.
>
> > Past the end of the file.
>
> Sorry, no. It might not even point at a valid FILE object at all.

It might not point to a valid "file" (whatever that is, concluding that
he meant a FILE object is pure guessing), but it definitely points past
the end of the file that the original pointer pointed to.

To be slightly more accurate, it will point past the end of the
FILE object.

I think Christian's point is that the OP never mentioned FILE, only "file".
C is case-sensitive. If that /is/ Christian's point, I think he's being a
touch over-pedantic (which is no bad thing in clc).

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <3F*********@earthlink.net> Joe Wright <jo********@earthlink.net> writes:

Dan Pop wrote:

In <bm**********@sunnews.cern.ch> I wrote:

>In <bm**********@oravannahka.helsinki.fi> Joona I Palaste <pa*****@cc.helsinki.fi> writes:
>
>>deepak <de*********@rediffmail.com> scribbled the following:
>>> hi folks
>>
>>> I have a pointer to a file. If i increment the pointer, where will it point.
>>> I could not find the problem in the FAQs.
>>
>>It's undefined.
>
>It's perfectly well defined: one byte after the current FILE object.
>The operation is perfectly OK, as long as you don't try to dereference
>the result (or pass it to some function expecting a valid FILE pointer).
>
>The following code has well defined behaviour:

Especially after applying the following patch ;-)

> FILE *mystdout == stdin;

s/stdin/stdout

> mystdout++;
> fprintf(--mystdout, "hello world\n");

I'd thought you'd have changed '==' to '=' as well.

Looks like a good idea, and it makes the compiler happy, too ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <bm**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:

Joona I Palaste wrote:

Richard Heathfield <do******@address.co.uk.invalid> scribbled the
following:

Dan Pop wrote:
In <bm**********@sunnews.cern.ch> I wrote:
>In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
><pa*****@cc.helsinki.fi> writes:
>>deepak <de*********@rediffmail.com> scribbled the following:
>>> hi folks
>>
>>> I have a pointer to a file. If i increment the pointer, where will it
>>> point. I could not find the problem in the FAQs.
>>
>>It's undefined.
>
>It's perfectly well defined: one byte after the current FILE object.
>The operation is perfectly OK, as long as you don't try to dereference
>the result (or pass it to some function expecting a valid FILE pointer).
>
>The following code has well defined behaviour:

Especially after applying the following patch ;-)

> FILE *mystdout == stdin;

s/stdin/stdout

...and the following following patch...

s/==/=/

Dang, Dan Pop made a mistake in *two* consecutive posts and I missed the
opportunity to gloat over it. =)

The Curse of Google Groups...

"many (most) programmers prefer to be _very_ careful when they type the
equality operator rather than compromise the readability of their code,
especially for the people who will have to maintain it later." - Dan Pop, 1
May 1995

Except when they know that the compiler *must* catch their mistakes ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[bd]

Dan Pop wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:

hi folks

I have a pointer to a file. If i increment the pointer, where will it
point. I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.

Do you mean sizeof(FILE) bytes beyond it?

[Irrwahn Grausewitz]

bd <bd*****@users.sf.net> wrote:

Dan Pop wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:
hi folks

I have a pointer to a file. If i increment the pointer, where will it
point. I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.

Do you mean sizeof(FILE) bytes beyond it?

No, one byte beyond it. Look:

FILE *p;

|current FILE object|
|sizeof(FILE) bytes |
+-+-+-+-+-+-+~~~~-+-+-+-+~~~~~~
^ ^
p before ... and after increment.

Regards
--
Irrwahn
(ir*******@freenet.de)

[Jeremy Yallop]

bd wrote:

Dan Pop wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:
hi folks

I have a pointer to a file. If i increment the pointer, where will it
point. I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.

Do you mean sizeof(FILE) bytes beyond it?

sizeof(FILE) bytes after the beginning of the object, or one byte
after the last byte of the object.

Jeremy.

[Micah Cowan]

Richard Heathfield <do******@address.co.uk.invalid> writes:

Micah Cowan wrote:

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <bm**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

> Christian Bau <ch***********@cbau.freeserve.co.uk> scribbled the
> following:
> > In article <7c**************************@posting.google.com >,
> > de*********@rediffmail.com (deepak) wrote:
> >> hi folks
> >>
> >> I have a pointer to a file. If i increment the pointer, where will
> >> it point.
> >> I could not find the problem in the FAQs.
>
> > Past the end of the file.
>
> Sorry, no. It might not even point at a valid FILE object at all.
It might not point to a valid "file" (whatever that is, concluding that
he meant a FILE object is pure guessing), but it definitely points past
the end of the file that the original pointer pointed to.

To be slightly more accurate, it will point past the end of the
FILE object.

I think Christian's point is that the OP never mentioned FILE, only "file".
C is case-sensitive. If that /is/ Christian's point, I think he's being a
touch over-pedantic (which is no bad thing in clc).

Er, yeah. Clearly a case of not reading too thoroughly before
posting...

-Micah

[bd]

Irrwahn Grausewitz wrote:

bd <bd*****@users.sf.net> wrote:

Dan Pop wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:

deepak <de*********@rediffmail.com> scribbled the following:
> hi folks

> I have a pointer to a file. If i increment the pointer, where will it
> point. I could not find the problem in the FAQs.

It's undefined.

It's perfectly well defined: one byte after the current FILE object.

Do you mean sizeof(FILE) bytes beyond it?

No, one byte beyond it. Look:

FILE *p;

|current FILE object|
|sizeof(FILE) bytes |
+-+-+-+-+-+-+~~~~-+-+-+-+~~~~~~
^ ^
p before ... and after increment.

Regards

Ah, I read it as one byte beyond the *start* of the current FILE object...

[Barry Schwarz]

On Sat, 18 Oct 2003 07:12:37 -0400, bd <bd*****@users.sf.net> wrote:

Irrwahn Grausewitz wrote:

bd <bd*****@users.sf.net> wrote:

Dan Pop wrote:

In <bm**********@oravannahka.helsinki.fi> Joona I Palaste
<pa*****@cc.helsinki.fi> writes:

>deepak <de*********@rediffmail.com> scribbled the following:
>> hi folks
>
>> I have a pointer to a file. If i increment the pointer, where will it
>> point. I could not find the problem in the FAQs.
>
>It's undefined.

It's perfectly well defined: one byte after the current FILE object.

Do you mean sizeof(FILE) bytes beyond it?

No, one byte beyond it. Look:

FILE *p;

|current FILE object|
|sizeof(FILE) bytes |
+-+-+-+-+-+-+~~~~-+-+-+-+~~~~~~
^ ^
p before ... and after increment.

Regards

Ah, I read it as one byte beyond the *start* of the current FILE object...

No, it is one byte beyond the ***end*** of the current FILE object.
Unless sizeof(FILE) is 1, these are not the same.

Consider an array of FILE objects and a FILE*.

FILE files[5];
FILE *ptr;
ptrdiff_t diff;
ptr = files;

ptr obviously points to files[0].

ptr++;

Just as obviously, ptr now points to files[1]. Like all arrays, the
five elements of files are consecutive in memory with no overlap and
no gaps.

diff = ptr-files;

Disregarding any type differences, the value in diff is guaranteed to
be equal to sizeof(FILE)
<<Remove the del for email>>