Reputation: 9
I am writing a program that reads virtual addresses (32 bit) integers from file and converts them to physical address. right now i am using fscanf to read each 32-bit integer from file. For some reason its not reading from the beginning of the text file. its starts reading from like the middle of the file.
e.g if you have the following numbers in file
16916
62493
30198
53683
40185
28781
24462
48399
64815
18295
12218
22760
57982
27966
54894
38929
it starts from like 18295. Intuitively i thought using fseek to set the pointer at the top would resolve it but it didn't.
My code please help.
int main(int argc, char *argv[]){
char FileName[100];
unsigned int LogicalAdd;
FILE *fp; // file pointer
unsigned int Offset;
int AmountRead = 0;
int FirstTime =0;
fp = fopen("addresses.txt", "r");
if(fp == NULL){
printf("Error: couldn't open file");
}
while((fscanf(fp, "%d\n", &LogicalAdd)) == 1){
printf("%d\n", LogicalAdd);
}
}
Upvotes: 0
Views: 1082
Reputation: 881113
That code should work fine as is, leading me to believe that maybe it's the file at issue(a).
For a start, make sure that you are reading the file you think you're reading by temporarily renaming it and making sure your code outputs an error. You should also return 1
if the file cannot be opened so as to not call fscanf
with a null pointer, and fclose
the file once you're done with it.
If you don't see the error when you've renamed the file, it may be that your code is running in a different directory than you think it is (some IDEs do this) and there's a file in there that's different from what you expect.
Another possibility is that there's something within the file which is causing an issue.
This sort of problem is usually detected by doing a hex dump of the file and ensuring all characters are valid. Under Linux, you could do:
od -xcb addresses.txt | less
and basically look for any character that's neither 0
through 9
nor a newline \n
.
If it turns out the file is okay, I hesitate to mention this but it could be simply because your terminal window or scrollback buffer isn't large enough to hold all the output.
By that I mean, if you have fifty lines in the input file and only forty lines in the terminal window, it may well look to the uninitiated that it starts partway through the data.
Even assuming you're not novice enough to fall for that, a 1000-line scrollback buffer with 1010 lines of output could have the same effect.
The best way to check for this is to pipe your program output through less
so that it shows you a page at a time, or redirect it to a file which you can then view in an editor.
For what it's worth, this is how I would have written the code, a minimalist approach which still runs correctly in the absence of the input file and which explicitly cleans up all resources before exit:
#include <stdio.h>
int main(void) {
unsigned int LogicalAdd;
FILE *fp = fopen ("addresses.txt", "r");
if (fp == NULL) {
printf("Error: couldn't open file");
return 1;
}
while (fscanf(fp, "%d\n", &LogicalAdd) == 1){
printf ("%u\n", LogicalAdd);
}
fclose (fp);
return 0;
}
(a) In fact, despite the minor issues, it does work, once you add the correct headers which I assume you just left out of the question. The following transcript shows both the code (header inclusion followed by exactly what you had):
pax> cat testprog.c
#include <stdio.h>
int main(int argc, char *argv[]){
char FileName[100];
unsigned int LogicalAdd;
FILE *fp; // file pointer
unsigned int Offset;
int AmountRead = 0;
int FirstTime =0;
fp = fopen("addresses.txt", "r");
if(fp == NULL){
printf("Error: couldn't open file");
}
while((fscanf(fp, "%d\n", &LogicalAdd)) == 1){
printf("%d\n", LogicalAdd);
}
}
and the output when compiled and run:
pax> gcc -o testprog testprog.c ; ./testprog
16916
62493
30198
53683
40185
28781
24462
48399
64815
18295
12218
22760
57982
27966
54894
38929
Upvotes: 3