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

[Arthur O'Dwyer via cfe-dev]

On Mon, Jun 28, 2021 at 1:44 PM Shoaib Meenai via cfe-dev <
cfe-dev at lists.llvm.org> 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.
>

I have heard of such things in theory, but this is the most explicitly
real-world-ish example I've seen yet. :)

Is this behavior desirable? You can construct a convoluted example that
> works when you copy a file and fails when you hard link it:
>

Yes, that makes sense to me.  "#pragma once" means roughly "Process *this
file* just once, even if you see *this file* being included multiple
times."  Obviously if you take this file and *copy* it, then you have two
files: namely, *this file*, and the copy you just made of it.  Whereas, if
you don't copy the file, then there's only one file: *this file*.
So Clang's behavior here seems teachable.


> gcc behaves the same as clang in this case, for what it’s worth.
>

That's a very good pragmatic reason to keep Clang's behavior the same. It
is kind of surprising that your "evil.h" example changes behavior depending
on whether you hardlink-or-symlink the *one* header file, or copy it so
that there are *two* header files.  However, it would be vastly, vastly
worse if your "evil.h" example changed behavior depending merely on which
compiler you used to compile it!
So Clang's behavior here seems good for the ecosystem.

my $.02,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210628/5687c37b/attachment-0001.html>