Date: Tue, 27 Aug 2024 11:35:45 -0500
This paper proposes #pragma once mean don’t #include the same contents
again. Unlike GCC which will perform multiple inclusion if mtime differs.
This paper leaves open the possibility of implementations doing their own
fast path checks of inode, stat, etc., but ultimately the file contents are
what matter.
Jeremy
On Tue, Aug 27, 2024 at 11:32 Gašper Ažman <gasper.azman_at_[hidden]> wrote:
> We have issues even with GCC - it doesn't work reliably, because mtime
> precision differs between filesystems, and so you end up with differing
> mtimes for the same file.
>
> On Tue, Aug 27, 2024 at 5:25 PM Jeremy Rifkin <rifkin.jer_at_[hidden]>
> wrote:
>
>> Hi,
>> Thank you for your comments.
>>
>> > #pragma once is unimplementable.
>>
>> Every notable C/C++ compiler has implemented it.
>>
>> > That's because it doesn't mean "don't include a file with the same
>> bytes"
>>
>> On GCC it more or less does.
>>
>> > And the second you have the same file accessible through two separate
>> fuse mountpoints, no amount of stat() will help you identify it's the same
>> file.
>>
>> This proposal does not propose any use of stat() for determining file
>> identity. I understand concerns regarding paths, links, and mounts and have
>> taken care in this proposal to propose a robust solution. This solution
>> proposed here should not cause problems in cases you refer to with your
>> build farms. If you can think of a way it would, I would be interested.
>>
>> Cheers
>> Jeremy
>>
>> On Tue, Aug 27, 2024 at 10:34 Gašper Ažman via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> #pragma once is unimplementable.
>>>
>>> That's because it doesn't mean "don't include a file with the same
>>> bytes", it means "don't include the same file". And the second you have the
>>> same file accessible through two separate fuse mountpoints, no amount of
>>> stat() will help you identify it's the same file.
>>>
>>> We hit this in our build-farms all the time, I had to write tooling to
>>> kill it.
>>>
>>> Don't make me explain this in-committee, again.
>>>
>>> On Tue, Aug 27, 2024 at 4:32 PM Tiago Freire via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> I like pragma once, should be standardized, but the problem is in the
>>>> details of the wording.
>>>>
>>>> I know that the paper acknowledges that some compiler issues a warning
>>>> if they appear in the source file, and that the paper doesn't advocate for
>>>> the warning either way. But the note seems to suggest otherwise.
>>>> It would be best if the standard had no notion of what a source file
>>>> is, and you should remove the note that a compiler could issue a warning,
>>>> let that just be a vendor detail.
>>>>
>>>> The description of how the directive should behave isn't the best,
>>>> describing in in terms of an ifdef block is not good.
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on
>>>> behalf of Jeremy Rifkin via Std-Proposals <
>>>> std-proposals_at_[hidden]>
>>>> *Sent:* Tuesday, August 27, 2024 4:01:08 PM
>>>> *To:* Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>>>> *Cc:* Jeremy Rifkin <rifkin.jer_at_[hidden]>
>>>> *Subject:* [std-proposals] Revising #pragma once
>>>>
>>>> Hi,
>>>> I have drafted a proposal for standardizing #pragma once. This has been
>>>> previously proposed a few years ago and I recognize that on top of being
>>>> difficult to standardize, existing opinions on this topic may render the
>>>> paper dead on arrival. However, due to its widespread nature and concerns
>>>> about portability contributing to it not being used more I think it's worth
>>>> revisiting. I have uploaded the first draft at:
>>>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html
>>>> .
>>>>
>>>> Cheers,
>>>> Jeremy
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
again. Unlike GCC which will perform multiple inclusion if mtime differs.
This paper leaves open the possibility of implementations doing their own
fast path checks of inode, stat, etc., but ultimately the file contents are
what matter.
Jeremy
On Tue, Aug 27, 2024 at 11:32 Gašper Ažman <gasper.azman_at_[hidden]> wrote:
> We have issues even with GCC - it doesn't work reliably, because mtime
> precision differs between filesystems, and so you end up with differing
> mtimes for the same file.
>
> On Tue, Aug 27, 2024 at 5:25 PM Jeremy Rifkin <rifkin.jer_at_[hidden]>
> wrote:
>
>> Hi,
>> Thank you for your comments.
>>
>> > #pragma once is unimplementable.
>>
>> Every notable C/C++ compiler has implemented it.
>>
>> > That's because it doesn't mean "don't include a file with the same
>> bytes"
>>
>> On GCC it more or less does.
>>
>> > And the second you have the same file accessible through two separate
>> fuse mountpoints, no amount of stat() will help you identify it's the same
>> file.
>>
>> This proposal does not propose any use of stat() for determining file
>> identity. I understand concerns regarding paths, links, and mounts and have
>> taken care in this proposal to propose a robust solution. This solution
>> proposed here should not cause problems in cases you refer to with your
>> build farms. If you can think of a way it would, I would be interested.
>>
>> Cheers
>> Jeremy
>>
>> On Tue, Aug 27, 2024 at 10:34 Gašper Ažman via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> #pragma once is unimplementable.
>>>
>>> That's because it doesn't mean "don't include a file with the same
>>> bytes", it means "don't include the same file". And the second you have the
>>> same file accessible through two separate fuse mountpoints, no amount of
>>> stat() will help you identify it's the same file.
>>>
>>> We hit this in our build-farms all the time, I had to write tooling to
>>> kill it.
>>>
>>> Don't make me explain this in-committee, again.
>>>
>>> On Tue, Aug 27, 2024 at 4:32 PM Tiago Freire via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> I like pragma once, should be standardized, but the problem is in the
>>>> details of the wording.
>>>>
>>>> I know that the paper acknowledges that some compiler issues a warning
>>>> if they appear in the source file, and that the paper doesn't advocate for
>>>> the warning either way. But the note seems to suggest otherwise.
>>>> It would be best if the standard had no notion of what a source file
>>>> is, and you should remove the note that a compiler could issue a warning,
>>>> let that just be a vendor detail.
>>>>
>>>> The description of how the directive should behave isn't the best,
>>>> describing in in terms of an ifdef block is not good.
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on
>>>> behalf of Jeremy Rifkin via Std-Proposals <
>>>> std-proposals_at_[hidden]>
>>>> *Sent:* Tuesday, August 27, 2024 4:01:08 PM
>>>> *To:* Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>>>> *Cc:* Jeremy Rifkin <rifkin.jer_at_[hidden]>
>>>> *Subject:* [std-proposals] Revising #pragma once
>>>>
>>>> Hi,
>>>> I have drafted a proposal for standardizing #pragma once. This has been
>>>> previously proposed a few years ago and I recognize that on top of being
>>>> difficult to standardize, existing opinions on this topic may render the
>>>> paper dead on arrival. However, due to its widespread nature and concerns
>>>> about portability contributing to it not being used more I think it's worth
>>>> revisiting. I have uploaded the first draft at:
>>>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html
>>>> .
>>>>
>>>> Cheers,
>>>> Jeremy
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
Received on 2024-08-27 16:35:58