On January 28, 2025 10:29:29 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.As
>>> per your example, if you correct the alignment when converting from void*
>>> => T*, why not generalize it for all T* <=> U*, and eliminate the extra
>>> T*=>void* before going from void*=>U*.

Such a conversion would not make sense from the language perspective. For
unrelated T and U, a T* pointer cannot point to an object of type U due to
the strict aliasing rule.

>>>>>> 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.The compiler gives you a general purpose fundamental type, and
>>>>>> you can customize it to your liking.>>> 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.But that model reflects the underlying hardware. No need to abstract it
>>>>>> away from the programmer.

The language defines a model that is implementable on different hardware.
This portability, as well as the intended semantics of pointers is the
reason to restrict the set of supported operations.

>>>