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