>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.
Exactly.
So if an implementation wants to manipulate bits to respect alignment from void* => T*
The question to which direction it should go?
Is it rounding up toward the highest memory alignment, or down to the lowest memory alignment, and why?
I didn't come across such case, that's why i assume the safest is to let the bits intact.
-------- Original message --------
From: Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>
Date: 1/28/25 9:06 PM (GMT+01:00)
To: Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org>
Cc: Andrey Semashev <andrey.semashev@gmail.com>
Subject: Re: [std-proposals] Make all data pointers intercompatible
>>> 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.
>>>
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals