can't read file?

[nick]

the following code is used to read a file called "input.txt"
# include <stdio.h>
int main(int argc,char *argv[]){
FILE *fp;
int ch;
fp=fopen("input.txt","r");
ch=fscanf(fp,"%d",&ch);
printf("%d\n",ch);

fclose(fp);
return 0;
}

the contains in "input.txt"
3
3 14
2 8
-1 0


when i run the program the output is:
1

what's going on?
why the output is not 3?

Nick

 

[Keith Thompson]

the following code is used to read a file called "input.txt"
# include <stdio.h>
int main(int argc,char *argv[]){
FILE *fp;
int ch;
fp=fopen("input.txt","r");
ch=fscanf(fp,"%d",&ch);
printf("%d\n",ch);

fclose(fp);
return 0;
}

the contains in "input.txt"
3
3 14
2 8
-1 0


when i run the program the output is:
1

what's going on?
why the output is not 3?

fscanf() returns the number of items scanned, which in this case will
be 1 if it succeeds. You're passing &ch as an argument to fcanf()
*and* you're assigning the result to ch. Don't do that.

(I'm not certain whether it invokes undefined behavior, but it's
certainly not what you want to do .)

 

[usr.root]

ch=fscanf(fp,"%d",&ch);
this line is the answer! because fscanf() return a int number 1,your ch
got it.
the true way was like this
fscanf(fp,"%d",&ch);
write like this is all ok,fscanf set value to ch,and you will found
the result is 3

best wishes

usr_root

 

[nick]

thanks!

 

[Keith Thompson]

ch=fscanf(fp,"%d",&ch);
this line is the answer! because fscanf() return a int number 1,your ch
got it.
the true way was like this
fscanf(fp,"%d",&ch);
write like this is all ok,fscanf set value to ch,and you will found
the result is 3

I think we've told you this before. Please pay attention this time.

You need to provide some context when you post a followup. Not
everyine has easy access to the parent article. It may not have
arrived yet, it may have expired, or somebody's newsreader might not
have a command to dispaly it.

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

And ask Google to fix their broken interface.

 

[Mike Wahler]

the following code is used to read a file called "input.txt"
# include <stdio.h>
int main(int argc,char *argv[]){
FILE *fp;
int ch;
fp=fopen("input.txt","r");
ch=fscanf(fp,"%d",&ch);
printf("%d\n",ch);

fclose(fp);
return 0;
}

the contains in "input.txt"
3
3 14
2 8
-1 0


when i run the program the output is:
1

what's going on?
why the output is not 3?

Look in your textbook. What does 'fscanf()' return?

-Mike

 

[usr.root]

Keith Thompson 写é“：

I think we've told you this before. Please pay attention this time.

You need to provide some context when you post a followup. Not
everyine has easy access to the parent article. It may not have
arrived yet, it may have expired, or somebody's newsreader might not
have a command to dispaly it.

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

And ask Google to fix their broken interface.

Thank you!i get it!

 

[Jack Klein]

the following code is used to read a file called "input.txt"
# include <stdio.h>
int main(int argc,char *argv[]){
FILE *fp;
int ch;
fp=fopen("input.txt","r");
ch=fscanf(fp,"%d",&ch);
printf("%d\n",ch);

fclose(fp);
return 0;
}

the contains in "input.txt"
3
3 14
2 8
-1 0


when i run the program the output is:
1

what's going on?
why the output is not 3?

fscanf() returns the number of items scanned, which in this case will
be 1 if it succeeds. You're passing &ch as an argument to fcanf()
*and* you're assigning the result to ch. Don't do that.

(I'm not certain whether it invokes undefined behavior, but it's
certainly not what you want to do .)

Can't have undefined behavior, 'ch' in modified twice, but there are
at least two sequence points between the assignments. The assignment
to 'ch' via the pointer passed to fscanf() must take place and
complete at a sequence point before the statement returning the value,
which itself is terminated by another sequence point.

And the assignment of the return value to 'ch' cannot take place until
after that return statement in fscanf().

No different than:

#include <stdio.h>
int int_3(int *ip)
{
*ip = 3; /* sequence point #1 */
return 1; /* sequence point #2 */
}
int main(void)
{
int i;
i = int_3(&i);
printf("%d\n", i);
return 0;
}

 

[Keith Thompson]

the following code is used to read a file called "input.txt"
# include <stdio.h>
int main(int argc,char *argv[]){
FILE *fp;
int ch;
fp=fopen("input.txt","r");
ch=fscanf(fp,"%d",&ch);
printf("%d\n",ch);

fclose(fp);
return 0;
}

[...]
fscanf() returns the number of items scanned, which in this case will
be 1 if it succeeds. You're passing &ch as an argument to fcanf()
*and* you're assigning the result to ch. Don't do that.

(I'm not certain whether it invokes undefined behavior, but it's
certainly not what you want to do .)

Can't have undefined behavior, 'ch' in modified twice, but there are
at least two sequence points between the assignments. The assignment
to 'ch' via the pointer passed to fscanf() must take place and
complete at a sequence point before the statement returning the value,
which itself is terminated by another sequence point.

And the assignment of the return value to 'ch' cannot take place until
after that return statement in fscanf().

Ok -- but doesn't that assume that fscanf() is implemented in C?

 

[Jack Klein]

the following code is used to read a file called "input.txt"
# include <stdio.h>
int main(int argc,char *argv[]){
FILE *fp;
int ch;
fp=fopen("input.txt","r");
ch=fscanf(fp,"%d",&ch);
printf("%d\n",ch);

fclose(fp);
return 0;
} [...]
fscanf() returns the number of items scanned, which in this case will
be 1 if it succeeds. You're passing &ch as an argument to fcanf()
*and* you're assigning the result to ch. Don't do that.

(I'm not certain whether it invokes undefined behavior, but it's
certainly not what you want to do .)

Can't have undefined behavior, 'ch' in modified twice, but there are
at least two sequence points between the assignments. The assignment
to 'ch' via the pointer passed to fscanf() must take place and
complete at a sequence point before the statement returning the value,
which itself is terminated by another sequence point.

And the assignment of the return value to 'ch' cannot take place until
after that return statement in fscanf().

Ok -- but doesn't that assume that fscanf() is implemented in C?

No, the C library does not need to be written in C, but it is defined
and prototyped in terms of C functions. No matter how it is actually
implemented, it must behave "as if" it was written in C.

 

[Keith Thompson]

No, the C library does not need to be written in C, but it is defined
and prototyped in terms of C functions. No matter how it is actually
implemented, it must behave "as if" it was written in C.

Hmm.

It's not a huge deal, but is that really true? If some hypothetical
CPU had a microcoded FSCANF instruction, would the C implementation
not be able to use it?

There's also the issue of library functions possibly being defined as
macros (I'm not sure yet about the interaction between functions and
macros with variable numbers of arguments).

I remember a discussion a while ago in which it was stated that
sin(x) + cos(x)
could invoke undefined behavior because the functions could be
implemented as macros, there's no sequence point between the calls,
and both can have the side effect of updating errno.

 

[Chris Torek]

... If some hypothetical
CPU had a microcoded FSCANF instruction, would the C implementation
not be able to use it?

That depends on whether it met the requirements.

As of C99, the scanf family of functions are a bit better defined
than they were in C89. C89 neglected to say just what, for
instance, happened with:

ret = sscanf("abc def ghi", "%s%n%s%n%s", buf1, &n, buf2, &n, buf3);

which writes into "n" twice with two "%n" conversions. (Define
appropriate types for all variables to make it otherwise well-defined.)
C99 says that the scanf family behave as if there are sequence
points between all the "%"-directive assignments.

I remember a discussion a while ago in which it was stated that
sin(x) + cos(x)
could invoke undefined behavior because the functions could be
implemented as macros, there's no sequence point between the calls,
and both can have the side effect of updating errno.

I, personally, am, ah, "less than thrilled" with this decision.
In a language like C that depends so heavily on side-effects,
programmers *should* have a guarantee that things that appear to
be function calls behave in all ways as if they were function calls,
even if they happen to be compiler-"built-in"s.

(On the other hand, C programmers should be aware of any stupid or
annoying constraints placed on them by the C standards. Whether or
not one decides to "break the rules", one should at least know the
rules first.)