CODEWITHSUNDEEP
cserializationendianness
Tom
Tom

Reputation: 119

serialize ints to big endian for storage

I wanted to follow the guidelines of Rob Pikes and store integers to disk without bothering about endianess. So, here's my test code:

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

typedef uint8_t   byte;

uint32_t _wireto32(byte *data) {
  uint32_t i =
    ((uint32_t)data[3]<<0)  |
    ((uint32_t)data[2]<<8)  |
    ((uint32_t)data[1]<<16) |
    ((uint32_t)data[0]<<24);
  return i;
}

void _32towire(uint32_t i, byte *data) {
  data[0] = (i >> 24) & 0xFF;
  data[1] = (i >> 16) & 0xFF;
  data[2] = (i >>  8) & 0xFF;
  data[3] =  i        & 0xFF;
}

void _dump(char *n, byte *d, size_t s, uint64_t N) {
  int l = strlen(n) + 9;
  fprintf(stderr, "%s (len: %ld, Num: %ld): ", n, s, N);
  size_t i;
  int c;
  for (i=0; i<s; ++i) {
    fprintf(stderr, "%02x", d[i]);
    if(i % 36 == 35 && i > 0) {
      fprintf(stderr, "\n");
      for(c=0; c<l; ++c)
        fprintf(stderr, " ");
    }
  }
  fprintf(stderr, "\n");
}

int main(int argc, char **argv) {
  FILE *fd = NULL;
  uint32_t n_orig = 20160809;
  uint8_t b[4];
  uint32_t n_new;

  if(argc != 2) {
    fprintf(stderr, "Usage: util w|r\n");
    exit(1);
  }

  switch(argv[1][0]) {
    case 'w':
      if((fd = fopen("buffer.b", "wb+")) == NULL) {
        perror("unable to write buffer.b");
        return 1;
      }

      _32towire(n_orig, b);

      fwrite(b, 4, 1, fd);
      close(fd);

      _dump("out", b, 4, n_orig);

      break;

    case 'r':
      if((fd = fopen("buffer.b", "rb+")) == NULL) {
        perror("unable to open read buffer.b");
        return 1;
      }

      if((fread(b, 1, 4, fd)) <=0)  {
        perror("unable to read from buffer.b");
        return 1;
      }

      close(fd);

      n_new = _wireto32(b);

      _dump(" in", b, 4, n_new);

  }

  return 0;
}

When I run this on a x86 system, everything looks fine:

% ./util w && ./util r
out (len: 4, Num: 20160809): 0133a129
 in (len: 4, Num: 20160809): 0133a129

Now if I transfer the output file to an big-endian system (aix on powerpc in my case), I get:

./util r
 in (len: 4, Num: 0): 0133a129

So, I'm obviously overlooking something. Does anyone have an idea?

Thanks, Tom

Upvotes: 1

Views: 1056

Answers (3)

Luciano
Luciano

Reputation: 2999

Although you have a mistake among fclose() and close() at: 

$ gcc tst.c -otst
tst.c: In function ‘main’:
tst.c:61:7: warning: implicit declaration of function ‘close’ [-Wimplicit-function-declaration]
       close(fd);
       ^

It works fine in AIX compiling with GCC v4.8.3, even with this mistake and warning. Maybe this version of gcc knows how to deal with casting from uint32_t to uint64_t. 

$ ./tst w
 out (len: 4, Num: 0): 0133a129
$ ./tst r
  in (len: 4, Num: 0): 0133a129

Just for knowledge, try an explicit cast in:

_dump(" in", b, 4, n_new);
_dump(" in", b, 4, (uint64_t)n_new);

But, your _dump() function could be fixed to receive the compatible type:

void _dump(char *n, byte *d, size_t s, uint32_t N) {
...
}

Just to show the powerpc (AIX) when I tested:

To show the endianess:

#include <stdio.h>

int main() {
    int n = 0x01;

    if ( ((char*)(&n))[0] == 1 && ((char*)(&n))[sizeof(n) - 1] == 0) {
        printf("This is a litte-endian plataform\n");
    } else if ( ((char*)(&n))[0] == 0 && ((char*)(&n))[sizeof(n) - 1] == 1) {
        printf("This is a big-endian plataform\n");
    } else {
        printf("Couldn't determine the endianess of this plataform\n");
    }
}

Running:

$ ./endianess 
This is a big-endian plataform
$ uname -a
AIX ???? 1 7 ???????????? powerpc AIX

Upvotes: 0

Lorinczy Zsigmond
Lorinczy Zsigmond

Reputation: 1910

gcc -maix32 says:

tom.c:27:3: warning: format '%ld' expects argument of type 'long int',
but argument 5 has type 'uint64_t' [-Wformat=]
fprintf(stderr, "%s (len: %ld, Num: %ld): ", n, s, N);

so do this:

fprintf(stderr, "%s (len: %ld, Num: %ld): ", n, s, (long)N);

When compiling always use this flags: -W -Wextra -Werror -pedantic

Upvotes: 2

Lundin
Lundin

Reputation: 213989

If you wonder why the big endian system prints Num: 0, then that's because of your _dump function taking uint64_t N and not 32 bits. On a big endian machine, the 4 most significant bytes are 0.

Upvotes: 2

Related Questions