fwrite() in c writes bytes in a different order

Question

#include <stdio.h>
#include <stdlib.h>


int main(void)
{
    int *int_pointer = (int *) malloc(sizeof(int));

    // open output file
    FILE *outptr = fopen("test_output", "w");
    if (outptr == NULL)
    {
        fprintf(stderr, "Could not create %s.\n", "test_output");
        return 1;
    }

    *int_pointer = 0xabcdef;

    fwrite(int_pointer, sizeof(int), 1, outptr);

    //clean up
    fclose(outptr);
    free(int_pointer);

    return 0;
}

this is my code and when I see the test_output file with xxd it gives following output.

$ xxd -c 12 -g 3 test_output 
0000000: efcdab 00                    ....

I'm expecting it to print abcdef instead of efcdab.

Answer 1

Which book are you reading? There are a number of issues in this code, casting the return value of malloc for example... Most importantly, consider the cons of using an integer type which might vary in size and representation from system to system.

• An int is guaranteed the ability to store values between the range of -32767 and 32767. Your implementation might allow more values, but to be portable and friendly with people using ancient compilers such as Turbo C (there are a lot of them), you shouldn't use int to store values larger than 32767 (0x7fff) such as 0xabcdef. When such out-of-range conversions are performed, the result is implementation-defined; it could involve saturation, wrapping, trap representations or raising a signal corresponding to computational error, for example, the latter of two which could cause undefined behaviour later on.
• You need to translate to an agreed-upon field format. When sending data over the write, or writing data to a file to be transferred to other systems, it's important that the protocol for communication be agreed upon. This includes using the same size and representation for integer fields. Both output and input should be followed by a translation function (serialisation and deserialisation, respectively).
• Your fields are binary, and so your file should be opened in binary mode. For example, use fopen(..., "wb") rather than "w". In some situations, '\n' characters might be translated to pairs of \r\n characters, otherwise; Windows systems are notorious for this. Can you imagine what kind of havoc and confusion this could wreak? I can, because I've answered a question about this problem.

Perhaps uint32_t might be a better choice, but I'd choose unsigned long as uint32_t isn't guaranteed to exist. On that note, for systems which don't have htonl (which returns uint32_t according to POSIX), that function could be implemented like so:

uint32_t htonl(uint32_t x) {
    return (x & 0x000000ff) << 24
         | (x & 0x0000ff00) << 8
         | (x & 0x00ff0000) >> 8
         | (x & 0xff000000) >> 24;
}

As an example inspired by the above htonl function, consider these macros:

typedef unsigned long ulong;
#define serialised_long(x)   serialised_ulong((ulong) x)
#define serialised_ulong(x)    (x & 0xFF000000) / 0x1000000 \
                             , (x & 0xFF0000)   / 0x10000   \
                             , (x & 0xFF00)     / 0x100     \
                             , (x & 0xFF)

typedef unsigned char uchar;
#define deserialised_long(x) (x[3] <= 0x7f \
                                    ? deserialised_ulong(x) \
                                    : -(long)deserialised_ulong((uchar[]) { 0x100  - x[0] \
                                                                          , 0xFF   - x[1] \
                                                                          , 0xFF   - x[2] \
                                                                          , 0xFF   - x[3] })
#define deserialised_ulong(x) ( x[0] * 0x1000000UL \
                              + x[1] * 0x10000UL   \
                              + x[2] * 0x100UL     \
                              + x[3]               )

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    FILE *f = fopen("test_output", "wb+");
    if (f == NULL)
    {
        fprintf(stderr, "Could not create %s.\n", "test_output");
        return 1;
    }
    
    ulong value = 0xABCDEF;
    unsigned char datagram[] = { serialised_ulong(value) };
    fwrite(datagram, sizeof datagram, 1, f);
    printf("%08lX serialised to %02X%02X%02X%02X\n", value, datagram[0], datagram[1], datagram[2], datagram[3]);
    
    rewind(f);
    
    fread(datagram, sizeof datagram, 1, f);
    value = deserialised_ulong(datagram);
    printf("%02X%02X%02X%02X deserialised to %08lX\n", datagram[0], datagram[1], datagram[2], datagram[3], value);
    
    fclose(f);
    return 0;
}

Answer 2

Use htonl()

It converts from whatever the host-byte-order is (endianness of your machine) to network byte order. So whatever machine you're running on you will get the the same byte order. These calls are used so that regardless of the host you're running on the bytes are sent over the network in the right order, but it works for you too.

See the man pages of htonl and byteorder. There are various conversion functions available, also for different integer sizes, 16-bit, 32-bit, 64-bit ...

#include <stdio.h>
#include <stdlib.h>
#include <arpa/inet.h>

int main(void) {
    int *int_pointer = (int *) malloc(sizeof(int));

    // open output file
    FILE *outptr = fopen("test_output", "w");
    if (outptr == NULL) {
        fprintf(stderr, "Could not create %s.\n", "test_output");
        return 1;
    }

    *int_pointer = htonl(0xabcdef);  // <====== This ensures correct byte order

    fwrite(int_pointer, sizeof(int), 1, outptr);

    //clean up
    fclose(outptr);
    free(int_pointer);

    return 0;
}