Date: Sun, 16 Nov 2025 13:59:48 -0800
> On Nov 16, 2025, at 4:49 AM, Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>> On Nov 14, 2025, at 3:38 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Similarly on desktop PC's, a page of memory can be toggled from
>> writable to read-only.
>
> How is that supposed to work?
Page tables? mmap?
> When I declare an integer const and initialize it, should it be written to an individual page that is then made read-only? That would be really wasteful.
Oh I see what you're saying - my interpretation of this proposal was not that `const` values would not be in immutable memory - because const in one place does not mean readonly memory. But that’s derived from the assumption that such an idea would not be workable, but the reason for this confusion is entirely due to a complete lack of any actual specification.
My guessed/inferred idea of the intended behavior was that you could specify an object should be placed in a location that would permit such toggling, and then it would be up to the developer to consider the memory cost of doing so.
It seems plausible that something like CHERI (very much a maybe), or maybe some future variant of MTE, could allow greater granularity of read/write permissions, but the AM is not concerned with how something is implemented only that an implementation can provide the required semantics - but this is well into implementation details that don’t belong in a specification, if there was one.
> Sure, the compiler could reserve a page for read-only objects that it makes writeable when it needs to add another variable. But, that would be slow and would add nothing for safety. Furthermore, we would not want to mandate this because it would disallow many optimizations. And obviously the compiler can (at least in theory) already figure out if something contains a mutable and place objects in the proper memory areas. We don’t need anything else in the standard for this kind memory optimization to work.
Many linkers already do this for lazy symbols, though again this is implementation details outside of the scope of the specification.
> I would claim, however, that it could be useful for the programmer to know this. Especially in the context of reflection this could be helpful. We still need good motivating examples for this. You haven’t provided any motivation so far how this would benefit the programmer (and not the compiler).
I do agree that this would not really belong in the specification, it feels like it would be a language extension or attribute based.
I think that there are contexts where this would be useful, but I think in the real world implementations (outside of the AM) this would fundamentally require hardware that has some mechanism to permit such read/write toggling in a way that could be efficiently implemented, meaning an MMU or MMIO mechanisms around non-ram storage, which would result in a lot of microcontrollers and embedded systems being unable to produce a conforming implementation (I guess maybe there could be an implementation defined limit on the amount of such objects that could be as low as zero?)
—Oliver
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>> On Nov 14, 2025, at 3:38 PM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Similarly on desktop PC's, a page of memory can be toggled from
>> writable to read-only.
>
> How is that supposed to work?
Page tables? mmap?
> When I declare an integer const and initialize it, should it be written to an individual page that is then made read-only? That would be really wasteful.
Oh I see what you're saying - my interpretation of this proposal was not that `const` values would not be in immutable memory - because const in one place does not mean readonly memory. But that’s derived from the assumption that such an idea would not be workable, but the reason for this confusion is entirely due to a complete lack of any actual specification.
My guessed/inferred idea of the intended behavior was that you could specify an object should be placed in a location that would permit such toggling, and then it would be up to the developer to consider the memory cost of doing so.
It seems plausible that something like CHERI (very much a maybe), or maybe some future variant of MTE, could allow greater granularity of read/write permissions, but the AM is not concerned with how something is implemented only that an implementation can provide the required semantics - but this is well into implementation details that don’t belong in a specification, if there was one.
> Sure, the compiler could reserve a page for read-only objects that it makes writeable when it needs to add another variable. But, that would be slow and would add nothing for safety. Furthermore, we would not want to mandate this because it would disallow many optimizations. And obviously the compiler can (at least in theory) already figure out if something contains a mutable and place objects in the proper memory areas. We don’t need anything else in the standard for this kind memory optimization to work.
Many linkers already do this for lazy symbols, though again this is implementation details outside of the scope of the specification.
> I would claim, however, that it could be useful for the programmer to know this. Especially in the context of reflection this could be helpful. We still need good motivating examples for this. You haven’t provided any motivation so far how this would benefit the programmer (and not the compiler).
I do agree that this would not really belong in the specification, it feels like it would be a language extension or attribute based.
I think that there are contexts where this would be useful, but I think in the real world implementations (outside of the AM) this would fundamentally require hardware that has some mechanism to permit such read/write toggling in a way that could be efficiently implemented, meaning an MMU or MMIO mechanisms around non-ram storage, which would result in a lot of microcontrollers and embedded systems being unable to produce a conforming implementation (I guess maybe there could be an implementation defined limit on the amount of such objects that could be as low as zero?)
—Oliver
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-11-16 22:00:00