change where a file pointer points, inside a function

[Don Pasquale]

The following function intends to delete "numberoflines" lines from a text
file, named "s" (string pointer) and pointed to by file pointer "fp", starting
from line "line".

Now, the function works an inteded, but I think that this is purely
coincidential.

I'm using a temp file to copy the contents of the text file, and then, copy
the last lines that i want to keep, on top of those i want to delete.I fwrite
an EOF character after the copied lines, so as to discard the rest of the
file.But this doesn't work!When I open the file with a text editor, I can see
the rest of the lines after a strange character, which evidently represents
EOF.

So, I reopened the temp file (discarding all previous content) and copied the
file again in to it (from start, till EOF, then fclosed it), changed its name
with that of the original file, and then fclose its pointer, and fopened it
using the original files pointer!And it works!The rest of the program uses the
"new" fp...., like it was the originaly fopened one, though its a different
pointer to a different file, only with the same name.

And that leads to the question:when we pass file pointers to functions, isn't
a local copy created?if I fclose a local copy of a file pointer inside a
function, then the "real" file pointer isn't left there dangling? Because from
this program's behavior, it seems like pass by reference is automaticaly used
for file pointers.
int delete_string_f(char* s,FILE* fp,int line,int numberoflines)
{
int check=1;
FILE* fp2=fopen("bak.txt","w+");
rewind(fp);
rewind(fp2);
/*copy the contents of the file pointed by fp to bak.txt*/
filecopy(fp,fp2);

/*move fp to the start of the line we want to delete*/
check=gotoline(line-1,&fp);
if(check==0)
{
printf("EOF encountered\n");
return -1;
}

/*move fp2 to the start of the line after the ones we want to delete*/
check=gotoline(line-1+numberoflines,&fp2);

/*copy the rest of the lines from fp2 on top of the lines we want to delete
from fp*/
if(check!=0)filecopy(fp2,fp);

/*make the file end after the lines we 've copied*/
fprintf(fp,"%c",EOF);

freopen("bak.txt","w+",fp2);
rewind(fp);
/*copying the file from start till the EOF we fprinted in to another file*/
filecopy(fp,fp2);

fclose(fp);
fclose(fp2);
/*remove the original file*/
remove(s);
/*rename the temp file with the original file's name*/
rename("bak.txt",s);
/*change where fp points*/
fp=fopen(s,"r+");

return 0;
}

[SM Ryan]

# I'm using a temp file to copy the contents of the text file, and then, copy
# the last lines that i want to keep, on top of those i want to delete.I fwrite
# an EOF character after the copied lines, so as to discard the rest of the
# file.But this doesn't work!When I open the file with a text editor, I can see
# the rest of the lines after a strange character, which evidently represents
# EOF.

Not every file system supports the notion of an end of file character. Unix,
for example, counts the number of bytes and uses that to determine end of file.
Even those that do have might have a different end of file (perhaps (char)26)
than (char)EOF.

In standard C, there's no way to truncate a file, except to truncate to empty
by openning with mode "w" or "w+". Write to the empty file and then close it,
and the system will handle any end of file markers.

Otherwise you'll need to investigate system specific functions, such
as ftruncate.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
We found a loophole; they can't keep us out anymore.

[Gordon Burditt]

>I'm using a temp file to copy the contents of the text file, and then, copy

the last lines that i want to keep, on top of those i want to delete.I fwrite
an EOF character
EOF isn't a character. And chances are, it won't fit in one
(except on wierd machines where sizeof(int) == 1, which
are legal per ANSI C).
after the copied lines, so as to discard the rest of the
file.
There is no portable way to discard the rest of the file, except
if you're chopping the file to 0 length (fopen(name, "w")), or if
you're copying the file. ftruncate(), chsize(), alakazam() and
truncate() are not portable.
But this doesn't work!When I open the file with a text editor, I can see
the rest of the lines after a strange character, which evidently represents
EOF.
There is no EOF character, but (char) EOF can exist and represent
some character.
So, I reopened the temp file (discarding all previous content) and copied the
file again in to it (from start, till EOF, then fclosed it), changed its name
with that of the original file, and then fclose its pointer, and fopened it
using the original files pointer!And it works!The rest of the program uses the
"new" fp...., like it was the originaly fopened one, though its a different
pointer to a different file, only with the same name. And that leads to the question:when we pass file pointers to functions, isn't
a local copy created?
A local copy of the *POINTER* is created.
A local copy of the FILE structure it points to is not.
if I fclose a local copy of a file pointer inside a
function, then the "real" file pointer isn't left there dangling?
Yes, it's left dangling. The next file you open might by chance
happen to allocate a FILE structure in the same place.
Because from
this program's behavior, it seems like pass by reference is automaticaly used
for file pointers.

Gordon L. Burditt

[Don Pasquale]

"Gordon Burditt" <go***********@burditt.org> wrote

A local copy of the *POINTER* is created.
A local copy of the FILE structure it points to is not.

if I fclose a local copy of a file pointer inside a
function, then the "real" file pointer isn't left there dangling?

Yes, it's left dangling. The next file you open might by chance
happen to allocate a FILE structure in the same place.

so it *did* work by chance....And any tampering with the FILE struct would
obviously be system dependant...
Anyway, thanks for the info.

--
Pascal Adoniou