[kazinator]

The worst thing that happens due to this "potential bug" is that someone introduces a double inclusion of that header, which fails to be suppressed and the build blows up in their face due to duplicate definitions.

The error could be diagnosed by the compiler---submit a patch to gcc!

That is to say, if the following pattern occurs around the content of the file:

   #ifndef <whatever0>
   #define <whatever1>

   #endif

the compiler can validate that <whatever0> and <whatever1> are the same symbol, and emit a warning if they aren't.

Note that GCC already looks for this pattern and optimizes it! That has been implemented for ages; probably twenty years if not more. See here:

https://gcc.gnu.org/onlinedocs/cpp/Once-Only-Headers.html

That optimization must have a check in place that it's the same symbol in both places. And so that piece of code which checks can probably be augmented to emit a warning fairly easily.

A sophisticated version of the warning would only kick in if the symbols appear to be similar (e.g. close by Levenschtein distance) so that one of them is plausibly a typo for the other.

Another solution is to have a commit hook which looks for such a problem: it enforces the include guard on headers, and checks that the symbols match.

[bluGill]

clang actually does have the warning you want gcc to have - this is how I found our instances of it.

What none of the above can do is two different projects have MESSAGE_H headers that are different can fully compatible to include both. #pragma once handles this correctly.

[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.