digitalmars.D.learn - What are the pointer aliasing rules in D?
- tmp (7/7) Mar 06 I come from a C/C++ background where the pointer aliasing rules
- Paul Backus (12/20) Mar 06 No, D does not have strict aliasing rules. Pointers of different
- =?UTF-8?Q?Ali_=C3=87ehreli?= (10/13) Mar 06 This topic came up among colleagues recently. I think such restrictions
- Dmitry Olshansky (9/25) Mar 06 ARM is like that, but I think you really must make a load out of
- Inkrementator (5/6) Mar 07 LDC and GDC offer nonstandard extensions to enable optimizations
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
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
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
On Thursday, 6 March 2025 at 16:11:37 UTC, Ali Çehreli wrote:On 3/6/25 6:34 AM, Paul Backus wrote:ARM is like that, but I think you really must make a load out of that pointer.are allowed to refer to the same memory location. However,there arestill cases where *dereferencing* those pointers can lead toundefinedbehavior.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.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
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