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]

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.

 

[Richard Heathfield]

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);
}
}

 

[Christian Bau]

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]

Past the end of the file.

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

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

 

[Christian Bau]

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]

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]

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

 

[Joe Wright]

Especially after applying the following patch ;-)

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

 

[Richard Heathfield]

Especially after applying the following patch ;-)


s/stdin/stdout

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

s/==/=/

 

[Joona I Palaste]

...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 ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola

 

[Micah Cowan]

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]

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]

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

 

[Dan Pop]

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]

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

 

[bd]

In <[email protected]> Joona I Palaste


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

Do you mean sizeof(FILE) bytes beyond it?

 

[Irrwahn Grausewitz]

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

 

[Jeremy Yallop]

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]

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