I like the sound of resolved path identity from search, including the
constructed full path and the index within include paths. if I was writing a
compiler from scratch, i'd problem do something like this:
SHA2(include-path-search-offset-integer-of-found-header-to-support-include-next)
+
SHA2
symbolic links
>>>>>>> and hard
>>>>>>> links without the fickleness of mtime?
>>>>>>
>>>>>> Not always. because inodes are not always stable on some file systems.
>>>>>> And also does not work with multi-mounted device
> >>>>> The whole definition of what is the same file is really up for
> >>>>> debate here.
> >>>>> I say if the file has the same content, then it is the same file and
> >>>>> GCC uses that definition. While clang says i
e file has the same content, then it is the same file and
>>>>> GCC uses that definition. While clang says it is based on if it is the
>>>>> same inode which is not always true because of file systems which
>>>>> don't use an inode number. While MSVC says
le, is a hard link to the same file
>>>> the same file or not; what about symbolic links? How about overlays
>>>> and mounted directories are they the same then?
>>>> GCC definition is the only one which supports all issues described
>>>> here dealin
ndif (and
> > that is documented here:
> > https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html) so does
> > it make sense to really standardize `#pramga once` here or just push
> > other implementations to add a similar optimization instead?
> >
> > Thanks,
> > A
ad?
>
> Thanks,
> Andrew Pinski
>
>>
>> Cheers,
>> Jeremy
>>
>> On Sep 6 2024, at 12:25 am, Andrew Pinski wrote:
>>
>> > On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote:
>> >>
>> >> Hello,
>> >&
emy
On Sep 6 2024, at 8:26 am, Ben Boeckel wrote:
> On Fri, Sep 06, 2024 at 00:03:23 -0500, Jeremy Rifkin wrote:
>> Hello,
>>
>> I'm looking at #pragma once behavior among the major C/C++ compilers as
>> part of a proposal paper for standardizing #pragma once. (Thi
2:25 am, Andrew Pinski wrote:
>
> > On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote:
> >>
> >> Hello,
> >>
> >> I'm looking at #pragma once behavior among the major C/C++ compilers as
> >> part of a proposal paper for standardizi
traditional
> include guards.
>
> Martin
>
>
>
> Am Freitag, dem 06.09.2024 um 00:03 -0500 schrieb Jeremy Rifkin:
>> Hello,
>>
>> I'm looking at #pragma once behavior among the major C/C++ compilers as
>> part of a proposal paper for standardizing #pra
fickleness of mtime?
Cheers,
Jeremy
On Sep 6 2024, at 12:25 am, Andrew Pinski wrote:
> On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote:
>>
>> Hello,
>>
>> I'm looking at #pragma once behavior among the major C/C++ compilers as
>> part of a proposa
On Fri, Sep 06, 2024 at 00:03:23 -0500, Jeremy Rifkin wrote:
> Hello,
>
> I'm looking at #pragma once behavior among the major C/C++ compilers as
> part of a proposal paper for standardizing #pragma once. (This is
> apparently a very controversial topic)
>
> To put m
m was that the regular form is not reliable and
difficult to standardize any specific rules and that the
form with ID does not add much value over traditional
include guards.
Martin
Am Freitag, dem 06.09.2024 um 00:03 -0500 schrieb Jeremy Rifkin:
> Hello,
>
> I'm looking at #p
On Thu, Sep 5, 2024 at 10:04 PM Jeremy Rifkin wrote:
>
> Hello,
>
> I'm looking at #pragma once behavior among the major C/C++ compilers as
> part of a proposal paper for standardizing #pragma once. (This is
> apparently a very controversial topic)
>
> To put my ques
Hello,
I'm looking at #pragma once behavior among the major C/C++ compilers as
part of a proposal paper for standardizing #pragma once. (This is
apparently a very controversial topic)
To put my question up-front: Would GCC ever be open to altering its
#pragma once behavior to bring it mo
15 matches
Mail list logo
