C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Make all data pointers intercompatible

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Tue, 28 Jan 2025 20:53:14 +0100
The compiler abstracts away a lot: Even basic stuff like the stack, local automatic variables and function parameters location or the registers - be it general purpose or vector registers.   C++ always had rules in its abstract machine to construct and destruct objects or for accessing data.       -----Ursprüngliche Nachricht----- Von:organicoman via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 28.01.2025 20:29 Betreff:Re: [std-proposals] Make all data pointers intercompatible An:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]>; CC:organicoman <organicoman_at_[hidden]>; >> 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 list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals   Sent from my Galaxy    -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2025-01-28 19:56:52