Date: Tue, 28 Jan 2025 20:29:23 +0100
>> 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*.>>> 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. -- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposalsSent from my Galaxy
Received on 2025-01-28 19:29:31