Magic numbers like this are useful in a lot of contexts. As the article says, they’re useful in on-disk formats. I added one a few months back to our firmware image format, in between the fixed size and variable sized bits of a header, so the loader can error if I get its headers and the linker script out of sync. They’re less useful in structures that are consumed and produced by the same code, where often a version field is more useful for being able to tell if something is modified, though they can be useful for error handling.
They become a knit more interesting if your memory allocator is sizeclass based and doesn’t reuse address space for different size classes. You can then use them to detect use after free bugs. I don’t believe the Linux kernel uses the, for this.
Even with sizeclasses, sequence numbers would still be better than magic numbers because that prevents problems within a type as well as type confusions.
Magic numbers like this are useful in a lot of contexts. As the article says, they’re useful in on-disk formats. I added one a few months back to our firmware image format, in between the fixed size and variable sized bits of a header, so the loader can error if I get its headers and the linker script out of sync. They’re less useful in structures that are consumed and produced by the same code, where often a version field is more useful for being able to tell if something is modified, though they can be useful for error handling.
They become a knit more interesting if your memory allocator is sizeclass based and doesn’t reuse address space for different size classes. You can then use them to detect use after free bugs. I don’t believe the Linux kernel uses the, for this.
Even with sizeclasses, sequence numbers would still be better than magic numbers because that prevents problems within a type as well as type confusions.