0

Here is the hexdump for the beginning of a file I am reading:

00000000 47 52 49 42 00 00 00 02 00 00 00 00 00 00 3d 0e |GRIB..........=.|
00000010 00 00 00 15 01 00 07 00 00 02 01 01 07 e4 02 12 |................|

I am reading it into the following structs:

    struct indicator_section
    {
      char fourcc[4];
      int16_t zeros;
      int8_t product_type;
      int8_t two;
      int64_t msg_len;
    };

    struct identification_section
    {
      int32_t twentyone;
      unsigned char one;
      //int16_t eight;
      unsigned char ea;
      unsigned char eb;
      //int16_t missing;
      unsigned char ma;
      unsigned char mb;
      unsigned char one1;
      unsigned char grib2_version;
      unsigned char one2;
      int16_t year;
      int8_t month;
      int8_t day;
    };

Notice the commented out int16_t declarations. If I uncomment it, and comment out the next two unsigned char declarations, then it reads one more octet than it should in this code:

    fread(&is,sizeof(is),1,fp);
    fread(&id,sizeof(id),1,fp);

int16_t should be the same size as two unsigned chars. Even the compiler thinks so when I check with the sizeof operator.

Here is the compiler info:

(base) $ cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)

How is this happening?

Craeft
  • 227
  • 1
  • 11
  • 2
    The magic word is "alignment"... look up alignment of variables in general and struct fields in particular. – Chris Hall Feb 25 '20 at 17:10
  • Check the `_Alignof(int16_t)` value for your compiler. It is probably 2, meaning that `int16_t` members are aligned on 2 byte boundaries in your `struct identification_section`. In that case, there will be one byte of padding between members `one` and `eight`. Depending on which members are commented out, there may also be one byte of padding between members `one2` and `year` and possibly two bytes of padding between member `day` and the end of the struct. – Ian Abbott Feb 25 '20 at 17:25
  • In GCC : `struct __attribute__ ((__packed__)) identification_section { ... } ;` or read the structure in one member at a time to align correctly. The file must either have been written that way (using a packed struct or member-by-member), or written on a system with different alignment. If exchanging files between systems note that they may have different byte order too. – Clifford Feb 25 '20 at 17:38
  • @Clifford Perfect! ```__attribute__ ((__packed__))``` was exactly what I needed! – Craeft Feb 25 '20 at 19:13

0 Answers0