CTFE limitation on reinterpreting cast
Rambutan
s56l6zk0w at mozmail.com
Tue Sep 29 18:23:27 UTC 2026
On Tuesday, 29 September 2026 at 11:19:15 UTC, user1234 wrote:
> I think this is not related to CTFE, that should just work in a
> `@system` scope. In other words, congrats you've found a bug.
Yes, seems like that.
The CTFE error message specifically forbids a narrow kind of cast
that doesn't change the underlying pointer, a "reinterpreting
cast". To me this seems to be a design choice not an accident.
Any information about this design choice will be gratefully
received. In the absence of that I will speculate some.
Using what a pointer obtained through a "reinterpreting cast"
points to is dangerous in general, with some exceptions of
course. So maybe forbidding reinterpreting casts in CTFE is a
security decision to avoid this dangerous use of reinterpreted
pointers during compilation.
This security decision is overkill because it prevents harmless
reinterpreting casts of pointers.
C can initialize arrays of structs at compile time to contain
cast pointers to global data but D cannot. Allowing D to do this
would be allowing harmless reinterpreting casts at compile time.
What makes a reinterpreting cast harmless in CTFE? When the
reinterpreted pointer is not used to access what it refers to.
When it is not used for indirection in any way at compile time.
So allowing "reinterpreting casts" for pointers, and disallowing
indirection for reinterpreted pointers is a far better CTFE rule.
This would likely enable D to more-or-less copy any C-style
compile-time initialization of big global arrays, which would be
great in a mixed source project that started as all C.
More information about the Digitalmars-d
mailing list