On Tuesday, 8 September 2026 at 09:43:22 UTC, Iain Buclaw wrote:
Note: D default initializes floating point and character types
to a non-zero mask, which necessitates the need for an `.init`
symbol.
To be compatible with C, use `= void` or `= 0`.
```d
struct b_real {
double val = void;
}
```
Ah, I should have put that in my example, it *is* everywhere in
the real .di file in the big project I mentioned. That's why I
was able to say this problem only exists when there's a double in
a struct.
$ gdc -o breal breal.o dmain.o cmain.o #di.o
/usr/bin/ld: breal.o:(.data.rel.ro+0x28):
undefined reference to `initializer for di.b_real'
I should have noticed the above missing initializer in my toy
example did not appear as a linking issue in the real world
version I'm working on, which it would presumably have done for
*every* struct without there being `= void` everywhere.
For the xtoHash and xopEquals functions, don't shy away from
raising a discussion against DMD - defer creating an issue till
later.
https://github.com/dlang/dmd/discussions
OK, I will look into this.
Without looking (or remembering) I suspect floating point
numbers might have non-trivial hashing requirement for edge
cases such as comparing `+0.0` and `-0,0`.
Ah, makes sense, and because of this sort of thing floating point
equality is more than bitwise equality. So this explains the need
for both xtoHash and xopEquals.
If it isn't publicly documented, it ought to be mentioned
somewhere.
But it is also true to say that if you are `new`ing the struct
on the GC, then runtime TypeInfo will *always* be pulled in
creating these sorts of dependencies.
Yes, I see that. So a .di file needs to be carefully constructed
if it is to be able to evade needing to be compiled as D and
linked in, and right now that cannot be arranged for a struct
containing a double.
I found that compiling and linking in di.di in the above example
did not resolve the missing xtoHash and xopEquals dependencies. I
had to rename it to di.d to do that.
Thank you for the detailed reply.
R.
