On Wed, 28 Aug 2024 at 02:54, Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Tue, Aug 27, 2024 at 6:27 PM Henry Miller via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>
>> On Tue, Aug 27, 2024, at 15:36, Ville Voutilainen via Std-Proposals wrote:
>> > On Tue, 27 Aug 2024 at 23:29, Tiago Freire via Std-Proposals
>> > <std-proposals_at_[hidden]> wrote:
>> >>
>> >> It's a clear-cut case of a feature that industry pretty much converged on, and the standard lagged behind.
>> >
>> > The industry refuses to use it because it doesn't work.
>> >
>> > Depending on the definition of "the industry" through a particular lens.
>>
>> Large portions of the industry uses it and find it works great in practice. Large portions of the industry refuse to use it, because there are significant edge cases where it doesn't work.
>>
>> I take the above facts as evidence that we should put something like #pragma once in the standard, but only if we either make it work in all cases; or understand and mitigate the edge cases. There are many options with trade offs. Some of the proposed mitigations I'm fine with, but others I'm not. [...]
>
>
> Here's a thought.
> My experience matches Tiago's: #pragma once Just Works, in every environment I have access to.
> But Gašper has said that his experience, in his environment, is different: #pragma once doesn't Just Work there. That is, to be precise, GCC handles the `#pragma once` syntax differently from how customers on that particular environment want it to be handled.
>
> It might be actually, practically useful, if someone with access to an environment like Gašper's, and GCC-hacking experience, would combine these to produce a compiler switch — something like `gcc -fpragma-once-hash-based`, or `-fpragma-once-timestamp-based`, or `-fpragma-once-something-else` — so that we could see what they are actually asking for. And then the GCC maintainers could consider whether to adopt an opt-in command-line switch like that. Then the few people in environments that require it, would put the switch into their build scripts, and then they could switch over to using `#pragma once` even in their environment.
>
> Right now I'm just seeing (a few) people saying "GCC's handling of #pragma once Doesn't Work for my environment," but with no concrete suggestions for how GCC ought to handle `#pragma once` in their environment.

Well, we don't have such suggestions. We don't know whether they
exist. Or, to phrase it differently, based on what we know, they
don't.
We are looking at a situation where you include the same header
multiple times via different paths, but those paths involve bind or
overlay mounts, and then the paths are different, the inodes are
different, mtimes may be
slightly different, and a #pragma once fails to recognize that we are
looking at a header that's already been seen. You can then fall back
on
content hashing if you like, but that's much slower than parsing an
include guard and skipping the file.

In other words, the quick and efficient "is it the same file?" checks
don't work, and the fallback that can give the correct answer is
prohibitively
expensive.

The solution to the problem is the use of include guards, and
avoidance of #pragma once.

So, the response to your request to implement what such users need is
that no implementation of #pragma once can do that because all data
that
it can look at is fallible and causes false negatives for the "is it
the same file?" checks. What is needed is an additional bit of
information, and that information
is an identifier for the header that is unique and not subject to such
fallibility. That identifier is what is used for an include guard.

Glad we sorted this out.