[kazinator]

The clash between two different MESSAGE_H can be rendered vanishingly unlikely by having a convention of adding some random digits.

I adopted the following pattern some twenty years ago of affixing a random 32 bit number in hex:

   #ifndef MESSAGE_H_3DF0_9A73
   #define MESSAGE_H_3DF0_9A73

   #endif

[loeg]

If only the filesystem would assign some sort of unique, 32- to 64-bit identifier to files that a compiler could use to distinguish one header from another. We could call them inode numbers. Hmm. No, I'm sure no one has ever thought of the problem of identifying unique files before.[0][1]

I guess instead we must embed GUIDs in every file to keep track of uniqueness.

[0]: https://stackoverflow.com/a/13172784/218830

[1]: https://stackoverflow.com/a/1866547/218830

[kazinator]

Copies of a file have different inode numbers.

[loeg]

I can agree with this statement of fact. I'm missing the part where it's relevant to the conversation or informs some conclusion.

[kazinator]

It's relevant if I have a requirement that if a file happens to be duplicated, then the once-include mechanism should treat those copies as one object.

This could arise if the code is originally on a system where some header files are symlinks to a common file. These symlinks happen to break (due to the way the code is archived, or on some system that doesn't have symlinks or whatever); they turn into separate copies.

Exclusion that is keyed to a symbol that is encoded in the file has no problem with this; filesystem-id-based excusion doesn't handle the case.

[loeg]

> It's relevant if I have a requirement that if a file happens to be duplicated, then the once-include mechanism should treat those copies as one object.

I don't believe that is a reasonable requirement.