>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.Sent from my Galaxy
-------- Original message --------From: Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Date: 1/28/25 9:06 PM (GMT+01:00) To: Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Cc: Andrey Semashev <andrey.semashev_at_[hidden]> Subject: Re: [std-proposals] Make all data pointers intercompatible 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.>>>-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals