BigFloat struct size is larger than mpfr_t

The Julia BigFloat struct has an extra field, _d, compared with the corresponding MPFR type mpfr_t. This doesn’t affect Base because the additional field is at the end of the type. However, one disadvantage is that sizeof(BigFloat) == 40 while sizeof(mpfr_t) == 32, and if one wanted to pass a C-allocated array of big floats via a pointer, then Julia’s ccall would issue a segmentation fault to any routine accessing past the first entry. This can be worked around with a dummy Julia struct that exactly replicates mpfr_t and a conversion to BigFloat, but then one may ask why it must be this way.

After presenting a strong argument against non-conforming BigFloat structs, in my opinion, I hope to hear the arguments for inclusion of the extra field.

BigFloat is a GC managed structure so there is just no valid usecase of “pass a C-allocated array of big floats via a pointer”, no matter now the memory management of the extra memory works. The “argument against non-conforming BigFloat structs” breaks down right there.

Ok, assume that Julia retains control of the memory management of BigFloat.

Currently, one cannot allocate an array of BigFloats in Julia and pass them to a C function as an mpfr_t *.

Correct, and that’s unrelated to the object size. You can pass it as an array of mpfr_t**

1 Like