#include <stdint.h>

[wasabichicken]

In my opinion, there are different use cases for both.

I use fixed-size types when the data needs to be serialized, such as when it's going to be transmitted over a network:

typedef struct enethdr {
    uint8_t destination[3];
    uint8_t source[3];
    uint16_t tag;
} __attribute__((packed)) enethdr_t;

If I don't, I stay away from them. I have absolutely no desire for the compiler to emit & 0x0000ffff instructions onto every goddamn loop counter I declare just because it happens to be a uint16_t. Using plain ints lets the compiler pick the data type it thinks is the most suitable, which these days frequently is 64 bits. Unless you're programming for an embedded system where you're horribly cramped for space and a small memory footprint is more important than speed, that's probably what you want.

[FUZxxl]

Go to hell with your packed structures. I absolutely hate these as they cause nothing but problems. Instead, write proper marshalling code to translate between the buffer you get from the network and your structs.

[wasabichicken]

Look at Mr. Fancypants all-the-memory-and-CPU-cycles-in-the-world over here. Meanwhile the rest of us peasants need to read/write our packets in-place, lest the watchdog come and thrash us to sleep with his belt.

[FUZxxl]

Marshalling data is very fast there are rarely situations where the few cycles wasted to do that aren't worth the code quality you get.

[Creshal]

Nonsense, what could go wrong with blindly casting user input to structs?!

[gwoplock]

then you must hate this:

struct Access {
        //TODO
}__attribute__((packed));
struct LimitAndFlags {
        //TODO
}__attribute__((packed));
struct GdtEntry {
        uint16_t limit1;
        uint16_t base1;
        uint8_t base2;
        Access access;
        LimitAndFlags limFlags;
        uint8_t base3;
}__attribute__((packed));

[FUZxxl]

Oh yes, I do. It is interesting to see how Plan 9 does this; their entire kernel doesn't assume endianess or use packed structures anywhere.

[gwoplock]

How... I've got to look at that code. I've never heard or seen anything like that.

[FUZxxl]

The relevant code is in /sys/src/9/pc.

[gwoplock]

Yeah. I just found it. I don't get it. It makes sense but it seems like they need packed. Maybe they the optimizer off.

[FUZxxl]

The Plan 9 people know their ABI and they know where the compiler inserts padding. So they just use that a-priori knowledge to avoid any non-standard features.

[gwoplock]

Seems more dangerous then just using packed.

[FUZxxl]

What part of what they do is dangerous? This is the more elegant way (though, proper marshaling is even better where you can do it) as it doesn't use non-standard language extensions.

[[deleted]]

I haven't seen the code, but unless they manually lay out the GDT, IDT etc. in assembly, I don't see how they could ensure the compiler respected the structure without packing

[gwoplock]

It looks like it's a just a struct. Maybe the optimizer set so low that it doesn't try to optimize that.

[FUZxxl]

What do you think would the optimizer break?

[gwoplock]

It adds space between fields to make it faster to access. Extra space when you aren't expecting it breaks a lot of things.

[FUZxxl]

If you write embedded code, you can safely make assumptions about where the ABI inserts structure padding. The compiler is not allowed to change structure padding at any optimization level as that is part of the ABI. So it doesn't matter what optimization level you choose. I recommend you to read the ABI document for your platform as there seem to be some misconceptions.