Thomas said:
Here is a compilable demo of the problem, with the input file below
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main() {
FILE *ifp;
int i,j;
float dummy;
char ref[10],filename[10]="test.csv",mode[10]="r";
ifp=fopen(filename,mode);
for (i=0;i<26;++i) {
for (j=0;j<5;++j) {
fscanf(ifp,"%f",&dummy);
printf("%1.1f ",dummy);
}
if(fscanf(ifp,"%f",&dummy)==0) {
printf(" Failed reading as number ");
printf(" dummy is now %f ",dummy);
fscanf(ifp,"%s",ref);
printf("%s\n",ref);
} else {
printf("Read as number !\n");
printf("%f\n",dummy);
}
}
fclose(ifp);
}
snip..
When I run this, there is no problem with NaN or Inf (fscanf converts
ok to float), but on 'i' and 'nn', the problem remains.
It seems that, instead of leaving the character in the input stream as
described in
http://www.eskimo.com/~scs/C-faq/q12.19.html
fscanf jumps to the next one, but only on these particular characters
(i, ii, n, nn).
Interestingly, with 'iii' or 'nnn', fscanf reads 'i' and 'n' resp. and
similarly if you increase the number of 'i's and 'n's..
I am sure there are workarounds, but I am quite curious about what is
happening..
I think Chris Torek's answer is the right one. When the
first non-white character encountered by "%f" is an 'i' or an
'n', it could be the beginning of "inf" or "nan". So fscanf()
reads the next character to try to match the remainder of the
"inf" or "nan", and if the next character is a newline the
match fails. However, the initial 'i' or 'n' has already
been read and accepted; here's what 7.19.6.2/9 has to say:
[...] An input item is defined as the longest sequence
of input characters [...] which is, or is a prefix of,
a matching input sequence. [...]
'i' and 'n' are prefixes of "inf" and "nan", so they are matched
and consumed by "%f". When the '\n' comes along the match fails,
but only the '\n' remains unconsumed: fprintf() can only push
back one character, and can't "rewind" the input to an arbitrary
position.
That explains what happens with "i\n" and "n\n", but it
doesn't explain the behavior on the "nn\n" line. I'd expect
the "%f" to consume the first 'n' as a prefix of "nan", then
choke on the second 'n' and push it back as a non-matching
character. Then your second attempt with "%s" should have
found the second 'n' again, followed by a newline, and should
have stored the one-character string "n" in `ref'. But it
looks like the second 'n' didn't get pushed back after the
matching failure, which may mean there's a bug in the fscanf()
implementation. (Or, of course, it may mean I've misread
what's supposed to happen; the possible forms of "nan" seem
to be pretty close to infinite ...)
For what it's worth, I tried your program on another
implementation and found what I think is a different incorrect
behavior: Both the "i" and the "nn" were read as strings by
the "%s" conversion. Thus, at least one of the implementations
is wrong -- and according to my (non-authoritative) reading of
the Standard, both are wrong!
So, what to do about your problem? Again, I think Chris'
suggestion is best: Don't use fscanf() to read lines of input.
Instead, use fgets() to read a line at a time and then use
other means -- possibly including sscanf() -- to pick them
apart. fscanf() doesn't always stop at a newline when you'd
want it to, but sscanf() absolutely *will* stop at a '\0',
and you won't "lose synchronization" with the input file.
