Cleaning up X server warnings(keithp.com) |
Cleaning up X server warnings(keithp.com) |
Interesting how the -Wcast-qual warnings are unfixable, so it shouldn't exist. Damned if you do, damned if you don't. A lot of warnings seem to fall on this.
Or warnings that would make sense on stricter languages but doesn't make sense on C exactly because of what you can do with C, like, for example, reading serialized data, then casting it to (MyStructure *)
And a little bit offtopic, but GTk have some unfixable warnings as well, something like "blah is not implemented in this platform" so, if I have to use this, but BLAH is not implemented, thanks for warning me, but shut up if I can't fix it
The exact layout of a structure in memory is up to the compiler, and can easily change with compiler options, even if the compiler itself and the target architecture and platform remain the same.
An externally-visible serialization format should of course be stable, and not depend on the compiler used to build the code, or the hardware platform which might have ideas of how various fields should be aligned (or even how to order the bytes in integers larger than 8 bits).
Serializing data is something you do, just blindly copying the run-time representation that you have to an external medium is not serialization. You should do it field by field, with a well-defined format chosen for each field.
Essentially, they are making use of const pointers to ensure that the code doesn't change the data. (gcc would throw a warning if you did). BUT: the problem comes when you want to free() the data. A strict interpretation of C would be that you can't free() something that's const, because it clearly is altering the data. However, you have to free the data sometime or other...
A possible workaround is to write a freeconst() macro that does the cast to void* and calls free(), and wrap this macro in the 'temporarily disable this warning #pragma'. This way, you only need to turn off the warning in one place in your code.
#define __DECONST(type, var) ((type)(uintptr_t)(const void*)(var))Even better would be a pragma that allows you to say the above, and also point to a test/test_suit that verifies that the specific case is still working right and warns on "something has changed, test foo no longer holds, here's the associated warning as a hint".
Perhaps they now need to compile the project with warnings-as-errors to enforce clean code?
Many programmers (and gcc apparently) live with the assumption that compiler warnings must always be fixed. This is largely false. Compiler warnings are there to help with additional information, not to be something to fix. There are many cases where the compiler issues a warning which must be ignored.
Many compilers support pragmas to silence a specific warning class in a specific point in the code. IMHO it's a much better approach to silence just a single warning instance where you know the compiler is getting the wrong assumption than silencing a whole warning class like the article suggests.
But it seems that in GCC you have no choice. Instead, code written with/for gcc often silences the warning by inserting some dummy code. For instance, the "unitialized warning" is usually fixed by assigning the variable to itself. It's shitty to look at, and someone that doesn't know this trick might wonder why this is being done.
I've reported a feature request many years ago, and it was quickly closed...
Also work for clang like so (replace clang with GCC for its version):
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wsomeignoredwarning"
triggered by this code
#pragma clang diagnostic popI recon you meant unused variables (as assinging an unitialized variable to itself would beat the purpose) you can use __attribute__((unused)) on it - normally #defined to a macro.
You can make a fair argument that using delete with a const pointer is a type error, after all the data can hardly be considered const if it has just been eradicated...
This does not apply to simply forking, of course, but it does apply to the "two processes" case in general.
Without that condition, you've got all the original problems, as listed. You can also have incompatibilities between compilers, or even compiler versions - e.g. gcc has ABI changes between some versions.
But the most common occurrence of this I can think are online games.
Endian issues are also a big problem here. The need to byte-swap everything eliminates a lot of the convenience.
It's also way too easy to make breaking changes to the struct, since there's no standard way to mark a struct as being something that you serialize/deserialize, and normally you can change struct fields at will in C code.
Just take the extra five minutes to write code to translate between your struct and a stream of bytes. It'll be easier to understand, less risky, and more compatible.
I don't see this as much of a problem as endianness, but yeah, maybe, x86 made us accustomed. And you can use portable types, defined on headers (linux does that, like u8, u16, etc)
But sometimes you know your target won't change (for a long time)
"It's also way too easy to make breaking changes to the struct, since there's no standard way to mark a struct as being something that you serialize/deserialize, and normally you can change struct fields at will in C code."
In the same way you can break your software doing any change. You can mark it with a naming convention but the easiest way is seeing the "pack" directives on it. And unit tests
"Just take the extra five minutes to write code to translate between your struct and a stream of bytes. It'll be easier to understand, less risky, and more compatible. "
Well, it's not five minutes. And it makes your program slower (for the most convoluted data types). A simple example:
http://en.wikipedia.org/wiki/BMP_file_format
And yes, GIMP reads field by field https://git.gnome.org/browse/gimp/tree/plug-ins/file-bmp/bmp...
I'm not quite sure what the BMP file format is supposed to be an example of, especially since file formats are separate from techniques used to read or write them.
Time was you might have to run on a SPARC or PowerPC or whatever. But x86 and little-endian ARM have pretty much won for most people.
I don't think my friend was right that this means you can totally ignore the issues, but I have to admit he was right that from a strictly practical perspective it's not the huge deal it was in the 90s. I agree with you that you don't know how the future will break you, but my guess is the momentum of binary compatibility will keep it so for a while.
To be honest I've even seen compilation issues coming up between ubuntu 10.x and 11.x. I don't worry about future targets that much. Until they're tested, I assume they will not work.
You know that at this moment they all support the right __attribute__((packed)) et co.. Bonus points for endianness crap.
OTOH I recall that insightful article from Rob Pike about how the "right" way to do it in a testable fashion is to not think in terms of swapping at all, and just do shifts that are portable regardless of architecture. http://commandcenter.blogspot.com/2012/04/byte-order-fallacy...
(By the way, in your 68k -> PPC -> Intel -> ARM example, the endianness only changes once. This was actually part of my friend's original argument, that endianness changes are even more costly than the instruction set, and platform vendors would be unwise to change it. "Modern" CPUs support both endianness types, so those shipping ARM platforms are in effect consciously deciding to be the same as Intel.)