[General] Re: CTFE limitation on reinterpreting cast

PermalinkReply

Here's a tiny version of something I ran into working on a project with both C and D source, while moving into D a C global array of structs that was initialized in place.

struct B {}
struct C {}

__gshared B Bobj;

auto ptr = cast(C*)&Bobj;

void main() {}

Without the cast the initializer &Bobj is fine, but with it this does not compile.

$ gdc ctfecast.d
ctfecast.d:6:20: error: reinterpreting cast from 'B*' to 'C*' is not supported in CTFE
    6 | auto ptr = cast(C*)&Bobj;
      |                    ^

Why? What can you tell me about this? Is there a workaround? Can you point me at connected documentation?

Any information about this will be gratefully received.

R.

PermalinkReply

On Monday, 28 September 2026 at 22:50:21 UTC, Rambutan wrote:

>

Here's a tiny version of something I ran into working on a project with both C and D source, while moving into D a C global array of structs that was initialized in place.

struct B {}
struct C {}

__gshared B Bobj;

auto ptr = cast(C*)&Bobj;

void main() {}

Without the cast the initializer &Bobj is fine, but with it this does not compile.

$ gdc ctfecast.d
ctfecast.d:6:20: error: reinterpreting cast from 'B*' to 'C*' is not supported in CTFE
    6 | auto ptr = cast(C*)&Bobj;
      |                    ^

Why? What can you tell me about this? Is there a workaround? Can you point me at connected documentation?

Any information about this will be gratefully received.

R.

initing is at compile time you want static this()

struct B {}
struct C {}

__gshared B Bobj;

C* ptr;// = cast(C*)&Bobj;
static this(){
	ptr=cast(C*)&Bobj;
}
void main() {}

Since its ct and therefore ctfe, the error your getting is from the colored gc of the ctfe, its largely undocumented but its mostly implemented to avoid work on bit logic when someone could imagine how it would compile different on different architectures

PermalinkReply

On Monday, 28 September 2026 at 22:56:52 UTC, monkyyy wrote:

>

Since its ct and therefore ctfe, the error your getting is from the colored gc of the ctfe, its largely undocumented but its mostly implemented to avoid work on bit logic when someone could imagine how it would compile different on different architectures

I should have said "is there a way to work around this at compile time?" instead of assuming that was implicit.

The pointer will be no different with or without the cast. If ptr is made __gshared the symbol name in the resulting object will be no different. With this change it still doesn't compile.

PermalinkReply

On Monday, 28 September 2026 at 23:14:10 UTC, Rambutan wrote:

>

On Monday, 28 September 2026 at 22:56:52 UTC, monkyyy wrote:

I should have said "is there a way to work around this at compile time?" instead of assuming that was implicit.

The pointer will be no different with or without the cast. If ptr is made __gshared the symbol name in the resulting object will be no different. With this change it still doesn't compile.

I believe only void* works void* ptr=cast(void*)&Bobj;; otherwise all the colored gc will get in your way. Im only aware of work around with type synchronicity and I probably have tried the hardest

PermalinkReply

On Monday, 28 September 2026 at 23:20:17 UTC, monkyyy wrote:

>

I believe only void* works void* ptr=cast(void*)&Bobj;; otherwise all the colored gc will get in your way. Im only aware of work around with type synchronicity and I probably have tried the hardest

I have had no trouble doing this with function pointers earlier. Here's a meaningless small example.

extern(C) int f1() { return 0; }

__gshared auto f2 = cast(int function(int,char*))&f1;

void main() {}

This compiles just fine.

PermalinkReply

On Monday, 28 September 2026 at 22:50:21 UTC, Rambutan wrote:

>

Here's a tiny version of something I ran into working on a project with both C and D source, while moving into D a C global array of structs that was initialized in place.
[...]
Why? What can you tell me about this? Is there a workaround? Can you point me at connected documentation?

Any information about this will be gratefully received.

R.

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.