-3

Perhaps I am misunderstanding something regarding the nature of the "packed" attribute, but it is my understanding that the below struct should pack to 16 bytes, rather than the normally padded 24 bytes. I can verify that the packed attribute is being applied (in general) as I have another struct defined in the same header file that is packed down from 16 bytes to 10 bytes. Is there any reason why the compiler would ignore the attribute without indicating via a warning?

To clarify, when I say that it does not appear to be packing, I am basing that off of the output of sizeof(foo) which returns 24 rather then the expected 16. The code in question is within a simple/crude custom kernel with very limited tools at the moment, so I have been relying on basic debugging via printing to screen.

I am using GCC 10.3.0 (on ubuntu).

    typedef struct {
      uint16_t m1;
      uint16_t m2;
      uint8_t m3;
      uint8_t m4;
      uint16_t m5;
      uint32_t m6;
      uint32_t m7;
    }__attribute__((packed)) foo;
Chris Waymire
  • 5
  • 2
  • 3
    Are you saying this doesn't pack to 16 bytes for you? It does for me, what compiler are you using? – Passerby Nov 01 '21 at 02:10
  • Seems fine with gcc and clang. https://godbolt.org/z/EKEG6Y1PP – Retired Ninja Nov 01 '21 at 02:28
  • 2
    Edit the question to provide a [mre], including the evidence the structure size is 24 bytes. – Eric Postpischil Nov 01 '21 at 02:47
  • GCC 1.3.0 on ubuntu. Running sizeof against the structure returns 24, I thought perhaps it was a quirk of sizeof but as I mentioned I have another struct in the same header that is being packed from 16 down to 10 bytes and sizeof returns the proper value for that one. There is no reason why this should not be working which is why I am so baffled by it. It is difficult to provide a minimal reproducible example given the nature of the code (very crude early stage hobby OS), but you can see the code https://github.com/waymirec/theos/blob/main/kernel/src/idt.c – Chris Waymire Nov 01 '21 at 03:44
  • 1
    I notice these standard types do _not_ come from `` in your code, but from your own `"types.h"`. Are you 100% certain that your type definitions resolve to the data sizes that you think they do? My guess is that `sizeof(unsigned long)` is actually 8. That would explain the 8 additional bytes you are getting. – paddy Nov 01 '21 at 04:00
  • You are absolutely correct. unsigned long is 8 bytes which accounts for the extra. – Chris Waymire Nov 01 '21 at 04:13
  • Fixing the type definitions resolved the problem. Your help has been greatly appreciated @paddy – Chris Waymire Nov 01 '21 at 04:27
  • 1
    You're welcome. Remember, 99% of the time when you're thinking something is wrong with the compiler, it turns out to be a mistake in your code. ;) – paddy Nov 01 '21 at 04:30
  • Voting to close as non-reproducible since this was a bug in some home-brewed header. The question holds no interest to future readers. – Lundin Nov 01 '21 at 11:13
  • no argument here – Chris Waymire Nov 02 '21 at 03:45

1 Answers1

0

As pointed out by paddy, the issue was an incorrect type definition for uint64_t which was resulting in an extra 4 bytes per, and the 2 of them in the struct resulted in the extra 8 bytes.

bguiz
  • 27,371
  • 47
  • 154
  • 243
Chris Waymire
  • 5
  • 2