direct access with fpos_t doesn´t work

[C. Sengstock]

Hi,
i want to save the keywords of an ini file in a struct, together with a
fpos_t. I think i´m right with the concept, but the access through fsetpos()
doesn´t work. The position is always wrong (except, in this example, the
first line).

My struct looks like this:
***
typedef struct {
char pname[32];
fpos_t pos;
} iniParam;

This routine reads the data and put it to "iniParam param[100]":
***
while (!feof (pFile)) {
fgetpos(pFile, &pos);
c=fgetc(pFile);
ungetc(c, pFile);
if(c == '#')
fgets (linebuf, 255, pFile);
else {
param[i].pos = pos;
fgets (linebuf, 255, pFile);
sscanf(linebuf, "%s", param[i].pname);
i++;
}
}

This routine reads the keywords and do a corresponding fscanf:
***
for(i=0; i<n; i++) {
if(strcmp(param[i].pname, "keyword1") == 0) {
pos = param[i].pos;
fsetpos(pFile, &pos);
fscanf(pFile, "%*s %d", &param1);
}
if(strcmp(param[i].pname, "keyword2") == 0) {
...

Don´t know why the access through a fpos_t position doesn´t work.
Thanks for any help, Chris

[CBFalconer]

"C. Sengstock" wrote:

"CBFalconer " wrote:

All complete C programs include an "int main(...) {" line, and
code cannot be generated outside of a function, which, in turn,
usually requires some sort of return statement.
Yep ... copy paste ready cody ...

#include<stdio. h>
#include<stdlib .h>
int main() {

int main(void) is better, but only a nit.
fpos_t position[50];
FILE* fp;
char line[200];
int i, n;

fp = fopen("myfile.t xt", "r");
if(!fp) perror("error opening file");
here, after detecting the error, you continue with the output.
This term should contain an exit(EXIT_FAILU RE); statement.
else {
i=0;
while(!feof(fp) ) {
if(fgetpos(fp, &position[i]) != 0) {
printf("error getting position\n");
exit(1);
}
if(fgets(line, 200, fp)==NULL)
break;
printf("%s", line);
i++;
}
}
n=i;
printf("\n*** output\n");
for(i=0; i<n; i++) {
if(fsetpos(fp, &position[i]) != 0) {
printf("error setting position\n");
exit(1);
}
fgets(line, 200, fp);
printf("%s", line);
}
fclose(fp);
return 0;
}

Now I pretty well have to look at it. :-) So I took your message,
snipped off the beginning and end, and:

[1] c:\c\junk>gcc -o fpos.exe fpos.c

[1] c:\c\junk>type fpostst.txt
#dontreadthis
baud = 4
#nodata

port = 50
parity = 6

[1] c:\c\junk>fpos
#dontreadthis
baud = 4
#nodata

port = 50
parity = 6

*** output
#dontreadthis
baud = 4
#nodata

port = 50
parity = 6

This is the results here, after changing the input file name. It
seems to do what you wanted, so you should look to your system.

Now you see how much easier it is for people to help if you give
them something to work with. I could criticise the lack of blanks
around tokens, but I won't :-)

One thought strikes me - does your test file have its last line
properly terminated with a \n? If not the funny termination
conditions might be causing the problem.

Of course the reread tells you nothing, since it is done in
sequence and thus the fsetpos doesn't have any work to do. Try
doing the reads in reverse order in the output section, i.e:

for (i = n-1; i >= 0; i--) {

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Chris Torek]

In article <m1************ *@usa.net>
those who know me have no need of my name <no************ ****@usa.net> wrote:

in comp.lang.c i read:

while(fgets(b uf, MAXLINE, infp) != NULL && !feof(infp))

the feof test is redundant.

Actually, it is not redundant: it is wrong. :-)

If fgets() returns NULL, we know that getc(infp) -- or some equivalent
operation -- returned EOF, but there are *two* reasons that getc()
might return EOF. One is "end of file", which would also set the
EOF indicator on the stream, making the feof() call redundant in
this (usual) case. The other, however, is "error reading stream".
You might, for instance, have this occur when reading from a bad
floppy disk. In this case the EOF indicator is *not* set on the
stream. Instead, the error indicator -- the thing tested by
ferror(infp) -- is set.

Thus, when reading from a bad floppy, the loop:

while (fgets(buf, MAXLINE, infp) != NULL && !feof(infp))

may run forever, calling fgets(), getting NULL due to ferror(infp),
and then seeing that feof(infp) is still 0.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.