Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

fread misreading character 255 1

Status
Not open for further replies.

robherc

Programmer
Apr 20, 1999
921
US
Hi; I've worked out all but 1 of the bugs in my first truly functional program in C.

The Bug:
Every time the fread() function in my program comes across a 0xFF character in the source file, it's feeding *something* outside the bounds of 0-255 into the corresponding unsigned char in my buffer array.

The fread call:
Code:
readLength = fread(inBytes, 1, 1000, inFile);
inBytes (defined earlier as unsigned char inBytes[1000]) is then passed into a switch:case function that tests each element of the array for values 0-255 inclusive. Characters are then converted to hexadecimal values & output into another file.
I can directly feed values 0-255 into elements of the inBytes array, and the output is perfect (no missed characters), but when fed from a file opened with:
Code:
inFile = fopen(fileName, "rb");
The output was missing several characters.
Noticing the error in the output, I added a default: case to the switch that inserted '--' in any "uncaught" character; then my output file had proper spacing, and I was able to compare the output to a different (not written by me) conversion program. From the output compares, I found that only "FF" characters were affected. Each "FF" character put out from the other program corresponded exactly to an "--" from my program; so what it causing this non-numeric output from fread() for only that one character?

Obviously, I could alter my default: case to output "FF" instead of "--", but that doesn't fix the *cause* of my glitch, so I can't be certain it won't lead to other conversion errors in the future if I do it; much better to find, understand, then fix the original glitch, than to apply a sloppy workaround.

BTW: I'm compiling using gcc on an x86_64 computer running 64-bit OpenSuse Linux, if it matters (although I'm trying to write the program to be fully portable to other platforms).
 
How sure are you of the contents of the file (have you looked with a hex editor?)

Can you adapt this runnable test case to make it show your problem?
Code:
#include<stdio.h>
int main (void)
{
  FILE *fp = fopen("test.bin","wb");
  for ( int i = 0 ; i <= 255 ; i++ ) {
    fputc(i,fp);
  }
  fclose(fp);
  fp = fopen("test.bin","rb");
  unsigned char buff[256];
  fread(buff,sizeof(buff),1,fp);
  fclose(fp);
  for ( int i = 0 ; i < 256 ; i++ ) {
    switch ( buff[i] ) {
      case 0:
        printf("Found 0 at position %d\n", i );
        break;
      case 255:
        printf("Found 255 at position %d\n", i );
        break;
    }
  }
  return 0;
}

$ gcc -std=c99 foo.c
$ ./a.out 
Found 0 at position 0
Found 255 at position 255
$ odx test.bin 
000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f  >................<
000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f  >................<
000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f  > !"#$%&'()*+,-./<
000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f  >0123456789:;<=>?<
000040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f  >@ABCDEFGHIJKLMNO<
000050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f  >PQRSTUVWXYZ[\]^_<
000060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f  >`abcdefghijklmno<
000070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f  >pqrstuvwxyz{|}~.<
000080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f  >................<
000090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f  >................<
0000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af  >................<
0000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf  >................<
0000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf  >................<
0000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df  >................<
0000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef  >................<
0000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff  >................<
000100

--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
 
Well, now I must admit to a moronic mistake.....

After a few shots at replicating the error by modifying your .c file with my functions, I found the problem, well, at least I found the *current* problem. After my "case 255:" statement, I'd forgotten to insert a "break;" before the "default" case, so default was overwriting the output of case 255. That still doesn't tell me what was wrong BEFORE I added the default case, but it does fix my program to where its output matches 100% to what I was expecting/hoping to see when I run both test.bin, and my target files it'd been failing on before, through it.

Moral of the story: Check your code, double-check your code, triple check your code, then be prepared to feel sheepish when someone you ask for help points out your dum typo! rofl.

Thanks Salem; I'd already spent several days pulling my hair out over that, and likely would've spent a couple weeks more!

I hope this helps;
robherc
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top