Can't get the exact hexadecimal value from reading a file

Question

Code =>

#include<stdio.h>

typedef struct {
    unsigned short c2;
    unsigned long c4;
} TAKECH;

int main() {
    TAKECH tch;
    FILE *fp_in;

    fp_in = fopen("in.txt","rb");

    fread(&tch,6,1,fp_in);

    printf("First two bytes: %x\n",tch.c2);
    printf("Next four bytes: %x\n",tch.c4);

    fclose(fp_in);

    return 0;
}

Output =>

First two bytes: 6261
Next four bytes: bfd56665

in.txt =>

abcdef

Hexeditor(vim editor :%!xxd) show this =>

0000000: 6162 6364 6566 0a                        abcdef.

Need explanation of output:

First two bytes: 6261 <-- Why is it in reverse order?

First two bytes: 6162 <-- Shouldn't this be?

Why can't I get 6364 in output? How can i get the next four bytes(6364 6566) with printf("Next four bytes: %x\n",tch.c4); Why do I get Next four bytes: bfd56665 , where does bfd5 come from?

Any answer will be highly appreciated.

Thanks in advance.

Answer 1

You should use a buffer for fread (see the example on http://en.cppreference.com/w/c/io/fread), not a struct.

Because of padding you're getting just two "correct" bytes from the file (65 and 66). The other bytes of c4 are uninitialized.

For the order "issue" you can take a look at: Why does fread mess with my byte order?

---

This is machine/compiler-dependent so actual results may vary.

typedef struct
{
  uint16_t c2;
  uint32_t c4;
} TAKECH;

sizeof(TAKECH) is 8 (not 6 = sizeof(c2) + sizeof(c4)): padding is added to satisfy alignment constraints (data structure alignment impacts both performance and correctness of programs).

typedef struct
{
  uint16_t c2;  /* 2 bytes */
                /* 2 padding bytes */
  uint32_t c4;  /* 4 bytes */
} TAKECH;

(see also Why isn't sizeof for a struct equal to the sum of sizeof of each member?).

Answer 2

First two bytes: 6261 <-- Why is it in reverse order?

Clearly you are running this code on a little-endian CPU architecture. Your issue relates to how bytes are ordered in memory.

Here's an explanation.

Answer 3

Hi might I suggest you clear your tch struct before assignment as it is filled with garbage.

Yeah I really don't understand why I got down voted here but you know I will add some code to prove my point:

mmcmbp:scratch abe$ cat main.c 

#include <stdio.h>
#include <string.h>

typedef struct {
    unsigned short c2;
    unsigned long c4;
} TAKECH;

int main() {
    TAKECH tch;
    FILE *fp_in;

    memset(&tch, 0, sizeof(TAKECH));

    printf("Before\n");
    printf("First two bytes: %hu\n",tch.c2);
    printf("Next four bytes: %lu\n",tch.c4);

    fp_in = fopen("in.txt","rb");

    fread(&tch,6,1,fp_in);

    printf("After:\n");
    printf("First two bytes: %hu\n",tch.c2);
    printf("Next four bytes: %lu\n",tch.c4);

    fclose(fp_in);

    return 0;
}

Compilation:

mmcmbp:scratch abe$ clang main.c -o main

Execution:

mmcmbp:scratch abe$ ./main

Before
First two bytes: 0
Next four bytes: 0
After:
First two bytes: 25185
Next four bytes: 0

And as per the ordering of the bytes, yes the endianness can dictate it and is what others have stated.

Answer 4

Most compilers support the "pack" pragma, which allows you to specify how struct members are laid out in memory. This example shows that packing with size-1 member alignment will make your struct match the file's layout. You don't want to use this kind of packing when you don't need it however, because it slows down performance and might cause other probblems because of misaligned memory accesses.

#include <iostream>
#include <cstring>

typedef struct {
    unsigned short c2;
    unsigned long c4;
} TAKECH;

#pragma pack(push,1)
typedef struct {
    unsigned short c2;
    unsigned long c4;
} TAKECH_packed_1;
#pragma pack(pop)

const unsigned char data[] = "\x61\x62\x63\x64\x65\x66\x0a\xff\xfe\xfd\xfc";

int main() {
    TAKECH original;
    std::memcpy(&original, &data, sizeof(original));
    std::cout << std::hex;
    std::cout << "Default packing:\n";
    std::cout << "    c2: " << original.c2 << '\n';
    std::cout << "    c4: " << original.c4 << '\n';

    TAKECH_packed_1 packed;
    std::memcpy(&packed, &data, sizeof(packed));
    std::cout << "\nByte packing:\n";
    std::cout << "    c2: " << packed.c2 << '\n';
    std::cout << "    c4: " << packed.c4 << '\n';
}

This outputs

Default packing:
    c2: 6261
    c4: ff0a6665

Byte packing:
    c2: 6261
    c4: 66656463

Answer 5

Your code would work if TAKECH were laid out like this:

    Low address                                 High address
    |        c2       |                  c4                |
    | Byte 1 | Byte 0 | Byte 3 |  Byte 2 | Byte 1 | Byte 0 |

but it's actually laid out like this:

    Low address                                              High address
    |        c2       |   Padding   |                  c4               |
    | Byte 0 | Byte 1 |      |      | Byte 0 | Byte 1 | Byte 2 | Byte 3 |

tch:    61       62      63     64      65       66    junk(d5) junk(bf)

The first issue, the ordering, is due to your computer being little-endian - the least significant byte of a multi-byte integer is stored at the lower address.

The second issue is due to your assumption that sizeof(TAKECH) is six.
It's not; it has been padded to make the address of c4 a multiple of sizeof(unsigned long).
This leads to part of tch (the "top" two bytes of tch.c4) being uninitialised when you only read six bytes.

A reliable and portable solution is to read each member separately,

fread(&tch.c2, sizeof(tch.c2), 1, fp_in);
fread(&tch.c4, sizeof(tch.c4), 1, fp_in);

and adjust the endianness afterwards.

Summary:

• Always use sizeof instead of relying on assumptions.
• When dealing with binary data, you must be aware of both padding and endianness.

Answer 6

Changing a TAKECH struct as follow :

typedef struct {
    unsigned short c2;
    unsigned long c4;
} __attribute__((packed)) TAKECH;

Here's an explanation about __attribute__((packed).

The byte order is up to a little-endian cpu or a big-endian cpu. If you executed your code in a big-endian cpu, your opinion was right. But The PC is a little-endian cpu. Currently the most platform used a little-endian mode, although supported a big-endian mode. Here's more detail.