Majority of the CoreCLR code is compiled against PAL headers that isolate from system C++ headers, and so the identifiers cannot collide by design.

It would nice to clean this up for parts of the tree that are likely to evolve into reusable components - GC is one that we know about so far.

@elfring We will be happy to accept PR that cleans up the header guards in files under src\gc. Thanks!

Should the affected source files be treated in a way so that they should be independent from a specific implementation of a C++ compiler?

We would like to make the GC portable by centralizing all dependencies on a specific execution engine, runtime and compiler in the GC environment (gcenv.h). See comment in https://github.com/dotnet/coreclr/blob/master/src/gc/sample/GCSample.cpp.

There is a number of issues to fix to get there. We prefer this type of work to be split into small incremental pull requests - e.g. fix one particular type of issue per PR.

Also, check the contribution guidelines for GC at https://github.com/dotnet/coreclr/wiki/Garbage-Collector-Contributions

cc: @Maoni0 @brianrob

What Jan said is fine by me. Thanks.

@elfring Did you get a chance to take a stab at this?

Also, would you mind if this title was changed to something like "C++ identifiers under src\gc need cleanup for portability"? We can open other issues to track work in other components as they are identified.

@MattWhilden: No.

Which safer name pattern do you prefer here?
How do you think about to make your include guards not only standard-compliant but also really unique by appending a kind of UUID?

I don't really have a strong preference. Perhaps @jkotas or @Maoni0 do.

Appending GUIDs makes the code look ugly and it is not really solving much. The remaining 99.9% of names can still collide. I do not think it is something we want to do.

Tweaking the number of underscores to make the guards more compliant with these guidelines is fine with me. Alternatively, changing them to #pragma once is ok too - though it is non-standard, but all current compilers support it.

Standard-compliant identifiers do not need to win a beauty competition, do they?

I agree with Jan - either #pragma once or getting rid of the double underscore is fine.

@elfring this is a very old issue. The guards appear to be the same and havent caused any issues. Can we close this now?

• How do you think about to avoid that this software depends on undefined behaviour?
• Were any questionable identifiers left over?

💭 Would you become interested to use a development tool like “clang-tidy” for corresponding source code adjustments?