Date: Tue, 28 Jan 2025 21:46:41 +0300
On January 28, 2025 9:26:39 PM organicoman <organicoman_at_[hidden]> wrote:
>> No, not "only". An implementation that e.g. >masks out the
>> least>significant bits of void* on conversion to T*, >according to
>> T's>alignment requirements, is possible. This will violate the strict
>> aliasing rule. And any type can alias any type.
I don't see how that would violate the strict aliasing rule, as it only
concerns valid pointers. Pointers that do not respect pointed object
alignment are not valid.
>>> Another implementation that e.g.>modifies tag bits in the pointer according
>>> to T >(e.g. to distinguish>between pointed types in hardware to >improve
>>> security) is also possible.This is counter intuitive, because you will get
>>> a page of unsecured memory with some cells tagged as secured, or the
>>> opposite which is worse.Manipulating bits of a pointer should be a
>>> programmer responsibility, not the implementation.
A programmer does not have the standard means to manipulate bits in a
pointer representation while maintaining pointer validity. Manipulating
object (including pointer) representation is the responsibility of the
compiler.
>>> Can you point where this is specified in the >standard?In the definition of
>>> the pointer type itself as a fundamental type.
I don't see where.
>> a pointer as a type defines 5 operations:++ increment , -- decrement ,
>> +ptr_diff_t add an offset, * dereference, (T*) castingNone manipulate bits.
The list of supported operations on pointers is irrelevant. This is just
the model that the language provides to users. It doesn't mean that an
implementation can't manipulate bits of pointer representation using any
instructions it sees fit.
>> No, not "only". An implementation that e.g. >masks out the
>> least>significant bits of void* on conversion to T*, >according to
>> T's>alignment requirements, is possible. This will violate the strict
>> aliasing rule. And any type can alias any type.
I don't see how that would violate the strict aliasing rule, as it only
concerns valid pointers. Pointers that do not respect pointed object
alignment are not valid.
>>> Another implementation that e.g.>modifies tag bits in the pointer according
>>> to T >(e.g. to distinguish>between pointed types in hardware to >improve
>>> security) is also possible.This is counter intuitive, because you will get
>>> a page of unsecured memory with some cells tagged as secured, or the
>>> opposite which is worse.Manipulating bits of a pointer should be a
>>> programmer responsibility, not the implementation.
A programmer does not have the standard means to manipulate bits in a
pointer representation while maintaining pointer validity. Manipulating
object (including pointer) representation is the responsibility of the
compiler.
>>> Can you point where this is specified in the >standard?In the definition of
>>> the pointer type itself as a fundamental type.
I don't see where.
>> a pointer as a type defines 5 operations:++ increment , -- decrement ,
>> +ptr_diff_t add an offset, * dereference, (T*) castingNone manipulate bits.
The list of supported operations on pointers is irrelevant. This is just
the model that the language provides to users. It doesn't mean that an
implementation can't manipulate bits of pointer representation using any
instructions it sees fit.
Received on 2025-01-28 18:46:44