On Wed, 02 Jul 2014 23:56:21 -0700 Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 7/2/2014 8:48 PM, Sean Kelly wrote: > > I'm still unclear whether we're aiming for C interoperability or > > hardware support though, based on Walter's remark about SPARC and > > PPC. There, 'long double' is represented differently but is not > > backed by specialized hardware, so I'm guessing D would make 'real' > > 64-bits on these platforms and break compatibility with C. So... I > > guess we really do need a special alias for C compatibility, and > > this can map to whatever intrinsic type the applicable compiler > > supports for that platform. > > What is unclear about being able to call a C function declared as: > > int foo(long double r); > > from D? I don't think that there's anything unclear about that. The problem is that if real is supposed to be the largest hardware supported floating point type, then that doesn't necessarily match long double. It happens to on x86 and x86_64, but it doesn't on other architectures. So, is real the same as C's long double, or is it the same as the largest floating point type supported by the hardware? We have erroneously treated them as the same thing, because they happen to be the same thing on x86 hardware. But D needs to work on more than just x86 and x86_64, even if dmd doesn't. We already have aliases such as c_long to deal with C types. I don't think that it would be all that big a deal to make it so that real was specifically the largest supported hardware type and then have c_long_double for interacting with C. - Jonathan M Davis
