www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What are the pointer aliasing rules in D?

reply tmp <imranuvin07 gmail.com> writes:
I come from a C/C++ background where the pointer aliasing rules 
make an assumption that pointers to different types cannot alias 
each other (with the exception of a pointer to char). This is 
known as the strict aliasing rule and while it can increase 
optimizations it makes it quite hard to write some low level code 
such as allocators or writing efficient memory copying functions.

Do the same rules exist in D? If they do, do workarounds exist?
Mar 06
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 6 March 2025 at 10:46:20 UTC, tmp wrote:

 I come from a C/C++ background where the pointer aliasing rules 
 make an assumption that pointers to different types cannot 
 alias each other (with the exception of a pointer to char). 
 This is known as the strict aliasing rule and while it can 
 increase optimizations it makes it quite hard to write some low 
 level code such as allocators or writing efficient memory 
 copying functions.

 Do the same rules exist in D? If they do, do workarounds exist?


No, D does not have strict aliasing rules. Pointers of different 
types are allowed to refer to the same memory location. However, 
there are still cases where *dereferencing* those pointers can 
lead to undefined behavior.

Some relevant sections of the language spec:

* [Memory Model][1]
* [Pointers][2]
* [Type Qualifiers][3]

[1]: https://dlang.org/spec/intro.html#memory-model
[2]: https://dlang.org/spec/type.html#pointers
[3]: https://dlang.org/spec/const3.html
Mar 06
parent reply =?UTF-8?Q?Ali_=C3=87ehreli?= <acehreli yahoo.com> writes:
On 3/6/25 6:34 AM, Paul Backus wrote:


 are allowed to refer to the same memory location. However, there are
 still cases where *dereferencing* those pointers can lead to undefined
 behavior.


This topic came up among colleagues recently. I think such restrictions 
come from CPU architectures where, as I remember reading on C++ forums 
years ago, the mere act of loading a misaligned pointer value into a 
pointer register would cause an error (trap?).

I cast any odd pointer value to any sized integer (and in one case to a 
struct pointer) from a void* buffer area and it works on the Intel CPU 
that I am working on.

Will this work on all or most modern CPUs?

Ali
Mar 06
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Thursday, 6 March 2025 at 16:11:37 UTC, Ali Çehreli wrote:

 On 3/6/25 6:34 AM, Paul Backus wrote:


 are allowed to refer to the same memory location. However,


 there are

 still cases where *dereferencing* those pointers can lead to


 undefined

 behavior.


 This topic came up among colleagues recently. I think such 
 restrictions come from CPU architectures where, as I remember 
 reading on C++ forums years ago, the mere act of loading a 
 misaligned pointer value into a pointer register would cause an 
 error (trap?).


ARM is like that, but I think you really must make a load out of 
that pointer.


 I cast any odd pointer value to any sized integer (and in one 
 case to a struct pointer) from a void* buffer area and it works 
 on the Intel CPU that I am working on.


As long as pointer is properly aligned for the data in question 
eg 4 bytes for int* pointer it should still work.


 Will this work on all or most modern CPUs?

 Ali


—
Dmitry Olshansky
dmitry at olshansky.me
https://olshansky.me
Mar 06
prev sibling parent Inkrementator <invalid invalid.org> writes:
On Thursday, 6 March 2025 at 10:46:20 UTC, tmp wrote:

 Do the same rules exist in D? If they do, do workarounds exist?


LDC and GDC offer nonstandard extensions to enable optimizations 
regarding non-aliasing pointers with the   restrict

https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gdc/Common-Attributes.html

https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/ldc/attributes.d
Mar 07