fread'ing binary data

I'm writing some simple command-line shell code to interface with embedded hardware.
In some cases, I need to move data between the hardware and Windows data files.
Where I need to interactively edit the data in a file, I'm using an external hex editor (NEO, in this case.)

All that works fine, until I read from a file and manipulate the data in C, and then, only when encountering a <0d> <0a> sequence in the file.
Even though I (think I) am opening the file in binary mode, the file system always collapses that sequence to simple <0a>, reporting one fewer byte read.

Code:

unsigned char buff[MAX_PACKET];
FILE * fp;
//
// Creating file:
  fp = fopen(fname, "wb");
  fclose(fp);
//
// Reading file:
  fp = fopen(fname, "rb");
  nb = fread (buff, sizeof(unsigned char), MAX_PACKET, fp);
  fclose (fp);
//
  printf ("%02x %02x %02x %02x %02x %02x %02x %02x\n", buff[0], buff[1], buff[2], buff[3], buff[4], buff[5], buff[6], buff[7]);

The external hex editor sees the data as expected, writes it, etc.
How do I get around this "feature"?

(I have also tried open() and read(), with no different results...)

Thanks,

Dave

I created a simple hex file with eight bytes (0x08 through 0x0f). The output of your code as posted above was:

Code:

08 09 0a 0b 0c 0d 0e 0f

Hence your claim that you are losing a byte upon read is incorrect.

EDIT: Just noticed that you are concerned about 0d 0a. Update again in a minute. Okay: I added 0a after the 0d byte, and now I get

Code:

08 09 0a 0b 0c 0d 0a 0e

so still not losing a byte. (I'm using MinGW on WinXP for comparison.)

Originally Posted by tabstop

Okay: I added 0a after the 0d byte, and now I get

Code:

08 09 0a 0b 0c 0d 0a 0e

so still not losing a byte. (I'm using MinGW on WinXP for comparison.)

Looks like it may be compiler/library dependent, then.
I'm using Bloodshed Dev_Cpp, with the free Borland command line tools (BCC55) under WinXP Pro. The Dev_Cpp tree includes mingw32 \bin and \lib\ldscripts (not much in the latter.)
Could I have the IDE configured wrong, and not using the right versions od some library?

Thanks!

I doubt this is a compiler/library problem. Can you post complete, compilable code that demonstrates the problem you are seeing?

Originally Posted by bithub

I doubt this is a compiler/library problem. Can you post complete, compilable code that demonstrates the problem you are seeing?

Not any more...
I compiled the absolute minimum few lines to read and dump the buffer, and it worked fine.
Went back to my full program, moved the declaration of buff[] out to a global, and when I recompiled, found a couple of places that now gave me warnings about argument type errors, that had not been warnings before(!).
Fixed those, and everything works as I expected in the beginning!

Thanks for the help - looks like a stupid error that slipped by the compiler.

Dave