On Mon, 2 Sept 2024 at 13:12, Tiago Freire <tmiguelf@hotmail.com> wrote:
> The (main) problem has never been two distinct files having the same path. The problem is one and the same file having different paths (and inodes, etc.).
It fails to be recognized as the Same File in multiple places, attempts to redefine non-inline entities, and builds break.

Great, don't do that then!

I think it's time you write a proposal for standardizing this simplistic form of #pragma once, and explain why the existing implementations that do something more complicated are unnecessary and should be changed to not do that.

Otherwise this discussion is going round in circles and you'll just keep insisting that the simplistic implementation is the right one, while others insist it doesn't work well enough.




-----Original Message-----
From: Ville Voutilainen <ville.voutilainen@gmail.com>
Sent: Monday, September 2, 2024 2:10 PM
To: Tiago Freire <tmiguelf@hotmail.com>
Cc: Jonathan Wakely <cxx@kayari.org>; std-proposals@lists.isocpp.org; Tom Honermann <tom@honermann.net>
Subject: Re: [std-proposals] Revising #pragma once

On Mon, 2 Sept 2024 at 15:02, Tiago Freire <tmiguelf@hotmail.com> wrote:
>
> > The reason #include "works" even if inode numbers are reused or
> > paths are not unique is not because including them by pathname makes
> > it work. It's because the headers files have include guards in them,
>
>
>
> Wrong! Unless you are modifying files as you compile. It has never happened that 2 distinct files occupy the same filepath and the compiler had to make a decision between one of them. (except maybe on a MAC, think smort… screw that platform).

The (main) problem has never been two distinct files having the same path. The problem is one and the same file having different paths (and inodes, etc.).
It fails to be recognized as the Same File in multiple places, attempts to redefine non-inline entities, and builds break.