0

Data at start of file in HEX 78000000 0300497B ..............

equating to int32 120 and char 03 followed by a load of other char data,

data written by another of my programs and viewed in hex dump mode.

When trying to read it back with another program I have tried..

int j,padNumber;
char rot;

j=fscanf(fp,"%d%c",&padNumber,&rot);  // insists on returning j=0,padNumber=0 & rot=0

whereas

char c1,c2,c3,c4,rot;

j=fscanf(fp,"&c&c&c&c&c",&c1,%c2,&c3,&c4,&rot);// gives 

j=5,c1='x',c2='\0',c3='\0',c4='\0',rot='!x03'

which equates to my on file data.

Why can't I get my int back in native format

WhozCraig
  • 65,258
  • 11
  • 75
  • 141
user3248730
  • 1
  • 2
    You do realize `fscanf()` parses platform-dependent **text** into native types, right? not raw bytes; *text*. So to answer the question asked, because you're using a function doesn't do what you think it does. – WhozCraig Jan 29 '14 at 12:46
  • 3
    If the data is stored in a *binary* file you can't use text-functions to read them. Read about the [`fread`](http://en.cppreference.com/w/c/io/fread) function. And remember to open the files in binary mode as well. – Some programmer dude Jan 29 '14 at 12:46
  • 1
    use `fread` with binmode. – BLUEPIXY Jan 29 '14 at 12:47
  • because this is anyway char in file, so you need to read string and then transform it to number, for example as discribed here http://stackoverflow.com/questions/10156409/convert-hex-string-char-to-int – Mike Minaev Jan 29 '14 at 12:47
  • 1
    @MikeMinaev the data isn't stored as a string of chars, its stored as a byte sequence, likely written using the equivalent of an `fwrite()` on a file in binary-mode. Text-translation has nothing to do with this (and in fact the assumption it does is directly related to the OP's problem). – WhozCraig Jan 29 '14 at 12:49
  • WhozCraig is correct. Mental block on the context of fscanf and its use, compounded by posts elsewhere stating the fscanf can fail on reading ints if it does not recognise the format. The fread fix is what I was after, which should NOT be a surprise as I wrote the int using fwrite in the first place. Thanks all. – user3248730 Jan 29 '14 at 14:17

1 Answers1

3

Use fread when reading from a native binary dump.

fread(&padNumber, sizeof padNumber, 1, fp);
fread(&rot, sizeof rot, 1, fp);

Or if you're on a Unix platform, the direct read syscall could work too.

#include <unistd.h>
...
read(fd, &padNumber, sizeof padNumber);
read(fd, &rot, sizeof rot);
SzG
  • 12,333
  • 4
  • 28
  • 41
  • 1
    Note this will only work if the *writer* of this data uses the same bit width of `int` data type *and* the same endian format. A 64-bit `int` system (regardless of endian format) while choke on this. Likewise a big-endian 32bit platform. Using `` and a known-width data type (ex: `int32_t`) if provided would be highly advised, and if the endian format of the reader doesn't match, a byte-shift assembly will be required (and should be done anyway if portability is an end-goal). – WhozCraig Jan 29 '14 at 13:02
  • Absolutely. That's why any sane person avoids binary dumps for data storage. – SzG Jan 29 '14 at 14:09