LTO type check warnings

[johnsonjh]

Of course I probably should have done this before 1.0 ... but sigh

I've had excellent luck using GCC (10+)'s LTO type checking to find interesting bugs on other projects. Most of the time, especially on GCC 10 or later, these issues do not cause any problems, but they can harm optimization and may be a source of trouble for non-GCC compilers, or older versions of GCC if -fno-strict-aliasing is not used.

Building with CCFLAGS="-flto=auto -Wl,-flto=auto" on modern GCC will enable LTO and the LTO type checking. Older GCC may need just "-flto" (no auto).

Some of the warnings are ...

It shouldn't be too hard to fix these. I can open an issue instead of a discussion if that's preferred.

[McDutchie]

I think these warnings must be the result of the fact that AT&T liked to use private type declarations with struct members that are hidden from the public API. An example is Sfio_t, where that is done here and here. It shouldn't harm anything as the public struct members are common between both versions. I am not sure why anything should necessarily have to change there, but I'm open to being convinced otherwise if there are good arguments.

Sometimes there is a reason to change it, e.g., I changed it for the Lex_t state struct for the shell lexer (which used to look like this). Several crash fixes required saving and restoring the lexer state, which requires sizeof(Lex_t) to be consistent if that is to be done without ridiculous workarounds.

[johnsonjh]

It's probably unnecessary if all of them like that case above. (And, if using -fno-strength-reduce it would be unnecessary, regardless of optimization level, for all almost any case.)

I've not looked at all of them, but at least the cases you pointed out would be safe, so nothing would pressing to change.

The argument for "fixing" them would be that eliminating them is low risk and might avoid potential problems down the road, as well as making new warnings of this type easier to spot.