GCC Unlikely To Adopt A "-Weverything" For Exposing All Possible Code Warnings

[Bsdisbetter]

I cannot forsee myself ever using this... does anyone that actually maintains a non-trivial piece of software want this?

Yes. on systems utilising clang we have it enforced. It is pretty much hated by all though as it exposes so much work to clean up especially on older code. Newer code is fine.

[Bsdisbetter]

Can you give examples? I've written countless drivers and other stuff for hardware that doesn't support unaligned accesses, but never once have I felt the need for a packed struct.

Openvms uses them heavily.

[Ansla]

In large projects, it's basically impossible to globally throw -Wall -Wextra without a bunch of -Wno-* waivers. Because of external code that can't be changed.

Actually, you're including the external code the wrong way. The compiler will only complain about the headers it found in paths specified using the regular `-I` argument. There is a special `-Isystem` to be used for paths containing code that can't be changed.

[AHSauge]

Sorry for a late reply, just logged in again, and saw this.

Can you give examples? I've written countless drivers and other stuff for hardware that doesn't support unaligned accesses, but never once have I felt the need for a packed struct.

Try communicating with third party items where they are okay with packing the structs. You'll have to choose between memcpy each field out or make a packed struct, and the copy into a non-packed struct.

What is the problem that you have with packed structs? I use packed structs extensively for on the wire protocols with thousands of external sources and have never once encountered a problem with packed structs in GCC and that is going back to 2.x when I begun to use GCC.

struct OrderbookDirectory {
char MessageType;
uint32_t Nanoseconds;
uint32_t OrderbookID;
char Symbol[32];
char Name[32];
char ISIN[12];
uint8_t FinancialProduct;
char TradingCurrency[3];
uint16_t NumberOfDecimalsInPrice;
uint16_t NumberOfDecimalsInNominalValue;
uint32_t OddLotSize;
uint32_t RoundLotSize;
uint32_t BlockLotSize;
uint64_t NominalValue;
} [B]__attribute__ ((packed))[/B] __attribute__((__may_alias__));

The main problem with packed structs, aside from the performance hit, is some HW don't even support it. This means that the compiler have to deal with it in software, which gives you even more performance hit. So far it's okay. However, what happens if you give someone a pointer to a member of your struct? Well, depending on your hardware you either get a performance hit, incorrect result or a crash. My daily work involves legacy code on HW where I can either choose between incorrect result or a crash. Naturally I go for the crash, and it's biting time and time again. It should be rewritten to avoid packed structures, but no time allowed for it

[Weasel]

The main problem with packed structs, aside from the performance hit, is some HW don't even support it. This means that the compiler have to deal with it in software, which gives you even more performance hit. So far it's okay. However, what happens if you give someone a pointer to a member of your struct? Well, depending on your hardware you either get a performance hit, incorrect result or a crash. My daily work involves legacy code on HW where I can either choose between incorrect result or a crash. Naturally I go for the crash, and it's biting time and time again. It should be rewritten to avoid packed structures, but no time allowed for it

This is why such HW is trash and people should stick to x86.

[AHSauge]

This is why such HW is trash and people should stick to x86.

Ehh...suuuure. You do realise that x86 is absolute trash for anything other than PCs, right? I deal with sub 1W devices and x86 is just simply not remotely an option. The best you can get is ARM Cortex MPUs, which for the record do have HW support for unaligned access (aka. packed structures)

[zyxxel]

What a bunch of idiots! There is good reason to want to throw all warnings. Beyond that who cares what some developers need, like most compiler switches they get turned on or off based on project needs.

Setiously it is no wonder CLang continues to see new adoption.

Us idiots are called professional developers. Us idiots have managed to collect a bit of experience. And "all warnings on" isn't so good as "non-idiots" might think.