[cfe-dev] Should hard links be distinct for #pragma once purposes?

[Nathan Sidwell via cfe-dev]

On 6/28/21 1:44 PM, Shoaib Meenai via cfe-dev wrote:
> We have a remote build system that uses content-addressed storage, in 
> which all files with the same content are hard linked. I noticed that 
> our output object files differed when they were compiled locally vs. 
> remotely, and it turns out that #pragma once considers hard links to be 
> identical, regardless of their path. Our local builds don’t have the 
> hard linking but our remote builds do, so the include tree is different 
> between local and remote builds (because of the #pragma once behavior 
> difference), which causes debug info to differ.

the behaviour you describe is the design intent of #pragma once (and 
#import and friends).  'The same file' is a defined by the content of 
the file, not by the name you use to refer to it.  Yes, this surprised 
me when I first met it.

feel free to reach out at work, if you need more help.

nathan
> 
> Is this behavior desirable? You can construct a convoluted example that 
> works when you copy a file and fails when you hard link it:
> 
> $ cat evil.h
> 
> #pragma once
> 
> #ifdef EVIL_ONE
> 
> #define EVIL_TWO
> 
> #endif
> 
> #define EVIL_ONE
> 
> $ cp evil.h evil2.h
> 
> $ cat evil.c
> 
> #include "evil.h"
> 
> #include "evil2.h"
> 
> #ifndef EVIL_TWO
> 
> #error Not evil enough
> 
> #endif
> 
> $ clang -c evil.c
> 
> # compiles successfully
> 
> $ rm evil2.h
> 
> $ ln evil.h evil2.h
> 
> $ clang -c evil.c
> 
> evil.c:4:2: error: Not evil enough
> 
> #error Not evil enough
> 
> ^
> 
> 1 error generated.
> 
> gcc behaves the same as clang in this case, for what it’s worth. 
> https://bugs.llvm.org/show_bug.cgi?id=26579 
> <https://bugs.llvm.org/show_bug.cgi?id=26579> looks related, although my 
> question is specifically about #pragma once’s intended behavior.
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 


-- 
Nathan Sidwell