Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

[Jonathan Newman]

Thanks everyone for the work on this so far. My own expectation as a regular user of #pragma once can be summarised as follows:

If a file (by which I mean a "regular file" according to stat, not a symlink etc) contains #pragma once, the preprocessor should behave as if that file has a unique include guard derived from the absolute path of that file, normalised appropriately e.g. case-insensitive on Windows.

In theory this definition would imply that some_header.h and a_symlink_to_that_header.h /should/ be recognised as the same file, and included only once. That's what gcc currently seems to do, but google suggests that older versions had different behaviour.

I would argue that as soon as the user starts introducing symlinks/hard links/weird in-memory filesystems/generally getting creative with the concept of what a "file" is, that user can hardly be surprised if #pragma once does something unexpected. The same goes for putting it in a conditional or other clever tricks :)

On Wed, 28 Jun 2023 at 20:29, draco <project.draco@gmx.net> wrote:

Pragma once is implementation defined, so I ponder a bit on the definition…

1. pragma once is defined on the file level, while regular source code can be amalgamated to a single source and in fact this is what the preprocessor does
2. does pragma once exclude the whole file from re-inclusion? And if so, is this true for wherever the pragma in the file is set? Can i pragma once in the middle of my header file?  Can I pragma once conditionally? What would be the consequences?
   
3. does pragma once therefor refer to a certain file? Or to the file content? What is a certain file? This is defined by the filesystem... On a harddisk, it means the physically same blocks on the drive, but what does it mean for different types off FS, lets say memory based? On linux we can use inode as a proxy, but win32 is lacking inodes… that’s the current problem to solve
4. So, how can any compiler safely assure a files identity? Is there any failsafe solution for the pragma once dilemma out there?
   

Moreover, do we really have projects, where headerA.h is symlinked to headerB.h (different filenames) and do we expect pragma once to exclude headerB? Is this sane behavior? What usecases are implied here?

Or can we safely assume, that two files with the same name, size and mtime are identical, even on windows?

So, the actual solution is good for linux (use dev/inode from stat) but not for win32, where every file is read and hashed. On the other hand, win32 does not use symlinks for files to myknowledge.

Thiago proposes a normalized path based solution. I would say, even easier, two files with the same tailname, size and mtime can be assumed to be identical in this context.

Michael

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel