Small C program unable to find file - Developers

I'm currently writing a C program to open a file, read, and output the number of characters it contains via the console. Unfortunately, it seems unable to find the file, no matter where I put it, or what file paths I type. [CODE] #include <stdio.h> #include <stdlib.h> #include <string.h> void main() { FILE *fpin; int ch; int count; char infile [256]; printf ("\nInput file name:\n"); gets (infile); if ((fpin=fopen (infile, "r"))==NULL) { printf ("Can't open file\n"); exit (0); } count=0; while ((ch=getc (fpin)) !=EOF) { count=count+1; } fclose(fpin); printf ("\nFile %s has %d characters\n", infile, count); } [/CODE] The target file to be read is test.txt. The file is currently in d:\documents\test.txt. Moving it into c:\ doesn't work, nor does placing it on the desktop. Any ideas?

If you don't pass the full file directory to fopen() it will look for the file relative to the current directory. So if you had your program in C:/foo/bin, assuming you didn't change the current directory, it would look for test.txt in C:/foo/bin.

Forgot to put this in; each time I compile, I receive this warning: warning #2181: Incorrect signature for entry-point 'main'; expected 'int __cdecl function(void)' but found 'void __cdecl function(void)'.

[QUOTE=QwertySecond;21229030]Forgot to put this in; each time I compile, I receive this warning: warning #2181: Incorrect signature for entry-point 'main'; expected 'int __cdecl function(void)' but found 'void __cdecl function(void)'.[/QUOTE] Should be "int main()" not "void main()" When you input the file name / path, double up on the slashes to escape them, for example - "D:\\Stuff\\test.txt"

[QUOTE=birkett;21229075] When you input the file name / path, double up on the slashes to escape them, for example - "D:\\Stuff\\test.txt"[/QUOTE] That would literally produce the text "D:\\Stuff\\test.txt". Character escaping is done by the compiler.

[QUOTE=jA_cOp;21229165]That would literally produce the text "D:\\Stuff\\test.txt". Character escaping is done by the compiler.[/QUOTE] GCC doesn't. Are you talking about MSVC?

[QUOTE=PvtCupcakes;21232792]GCC doesn't. Are you talking about MSVC?[/QUOTE] Did you see his program? It uses gets for input. edit: And... did you read my post? I said it's done by the compiler... and GCC does in fact use \ for escaping characters, just like every other C compiler.

[QUOTE=jA_cOp;21233271]Did you see his program? It uses gets for input. edit: And... did you read my post? I said it's done by the compiler... and GCC does in fact use \ for escaping characters, just like every other C compiler.[/QUOTE]This. The compiler handles escape characters. They aren't the same as format strings, which you guys seems to be confusing ECs with. It wouldn't matter anyway, since neither gets() nor fopen() are formatted.

[QUOTE=jA_cOp;21233271]Did you see his program? It uses gets for input. edit: And... did you read my post? I said it's done by the compiler... and GCC does in fact use \ for escaping characters, just like every other C compiler.[/QUOTE] Oh right. Yeah if he types it into the command prompt, it's one \. I missed that part.

[QUOTE=birkett;21229075]Should be "int main()" not "void main()"[/QUOTE] Well, I've never seen that before. Thanks! Still not working correctly for me. At the point where FILE is declared: [code] int main() { FILE *fpin; int ch; int etc. [/code] FILE is not highlighted blue (unlike the other variables). Does this mean anything specific? Also, I'm using Pelles C, if that makes any difference.

[QUOTE=QwertySecond;21262994]FILE is not highlighted blue (unlike the other variables). Does this mean anything specific?[/QUOTE] No, it's because C syntax highlighters are known to suck (I'm not sure why, it should be possible to write a good static analysis tool for C)

"int" is colored blue because it's a reserved word, like "for" and "return" and "const". Reserved words are words whose meaning is defined by the language itself, and can't ever be made to mean anything else. (You can't write a function called "int()", for example.) "FILE" is not a reserved word. The <stdio.h> header happens to define a struct by that name, but if you didn't include <stdio.h> you could use it as a variable name, or make a FILE() function, or whatever. The name has no special built-in meaning.

That's true, but it *should* highlight to say it's a type. I don't know why C IDEs don't do that.

Because it's a pain in the ass to implement.

Yep. "FILE" might not actually be the name of a struct; it might refer to something like a preprocessor macro that (#define) that gets replaced with different things depending on #if conditions at compile time. Figuring out what an identifier represents is more complicated for C/C++ than for higher-level languages because of the preprocessor.

Why not ignore the preprocessor then? FILE is just a typedef after all

Because when you ignore the preprocessor you end up with shitty results. Really the best way would be to hook into your compiler I reckon, provided you can get it fast enough. It'd probably work pretty well for C, but for C++ not so. Just read the blog post about what the VS team has done to get the C++ code completion in 2010 for an idea. Generally it's just not worth the bother.

[QUOTE=turb_;21275065]Why not ignore the preprocessor then? FILE is just a typedef after all[/QUOTE] If you ignore the preprocessor then FILE might not be anything at all: [cpp] typedef struct { /* ... */ } _File; #define FILE _File [/cpp] Or it might be several conflicting things: [cpp] #ifdef FOO typedef _FooFile FILE; #else typedef struct { /* ... */ } FILE; #endif [/cpp]

Obviously ignoring the preprocessor wouldn't lead to perfect results, but in the second example if the analyzer ignores the preprocessor, it still knows the FILE is a typedef.

Patchy half working analysis is worse than none at all.

The preprocessor is piss fast anyway, nothing says you can't just run the preprocessor before analyzing.