RFR (tedious) 8216022: Use #pragma once

[Erik Österlund]

Hi Andrew,

On 2019-01-05 12:31, Andrew Haley wrote:
> On 1/4/19 3:59 PM, Erik Österlund wrote:
> 
>> On 2019-01-04 15:59, David Lloyd wrote:
>>> In addition, it was pointed out to me that if, for some reason, a
>>> header file ends up in more than one location on the include path,
>>> #pragma once will (probably, as it's not standardized) allow it to
>>> be included twice, which #ifdef guards avoid.  This is perhaps not
>>> a real concern in this particular code base though.
>>
>> That sounds like a bug. Just because something is implementation
>> defined, doesn't make it okay or expected to not work. Do you know
>> how to reproduce this, and on which platform/compiler/version?
>> Obviously, if this was an issue in our code base, one would quickly
>> notice it doesn't build.
> 
> It's not a bug, exactly. It's that the question of "is this the same
> file?" is extremely difficult to answer definitively. Not all
> filesystems give you a reliable way to answer that question. Sure, you
> can kludge around the problem with modification times and maybe even a
> collision-free hash, but getting it really correct is not going to be
> efficient, and not even possible until that question is rigorously
> defined. There's a good reason why #pragma once still isn't standard.
> 

Perhaps. Yet Java has to support Path.toRealPath(), which resolves 
symlinks. And similarly, realpath() has been part of the POSIX standard 
since 2008. And even C++17 defines std::filesystem::canonical() as part 
of the standard. So it seems to me that any system that can't build 
HotSpot because of the inadequacy of the underlying system to tell 
symlinked files apart, will also not be able to support said 
standardized APIs either. Unless again someone shoots himself/herself in 
the foot intentionally and actually keeps 2 copies of the same file 
around, and includes both. We should *never* do that, and I would love 
to get a compiler error if anyone tried to do that.

I have asked this before, but does anyone actually know of a 
compiler/os/filesystem combo that has a #pragma once implementation that 
gets confused about symbolic links or different include paths, or is 
this all a hypothetical problem, for a hypothetical 
compiler+os+filesystem combo that can probably never support e.g. C++17? 
Perhaps a simple test could be written for this that fails reliably on 
such systems, so we don't get any surprises. I would rather test this to 
see if it is a problem or not, instead of having a long hypothetical 
argument about it, based on what somebody told somebody, with guesses 
about how relevant compilers may or may not handle this differently and 
may or may not have different interpretations about whether files should 
be canonicalized or not.

Also, the principle of optimizing for the normal common case yet 
allowing the odd uncommon case has value. If there exists some 
hypothetical scenario that could in theory be produced, yet never 
happens and arguably will never happen in HotSpot (and would immediately 
fail to build if it occurred), then I don't see why that should block us 
from making our lives easier. Sure, maybe somebody eventually wants to 
do some recursive self-include fixed-point iteration magic like Hans 
Boehm's libatomic. You probably don't want to do that. But you still can 
do that in those particular files. That doesn't have to constrain the 
rest of the code base, and dictate the rules for all other files. 
Especially when there are zero such exceptional cases present. This was 
the reasoning behind #import in Objective-C as well. There were 
hypothetical scenarios where you would need #include instead of #import. 
It sure never happened to me or anyone I know or heard of in reality. 
But if you really had to, for whatever reason, you could. But that 
shouldn't stop you from living an easier life in the 99.99% scenario.

And remember, converting back can be easily done with a script at any 
time, should we run into trouble at any point in the future, and hit the 
wall, because we really need this to build with the Cray C/C++ compiler 
or whatever.

Thanks,
/Erik