Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for native long double using Java BigDecimal #290

Open
basshelal opened this issue Jan 2, 2022 · 0 comments
Open

Add support for native long double using Java BigDecimal #290

basshelal opened this issue Jan 2, 2022 · 0 comments

Comments

@basshelal
Copy link
Contributor

The largest precision floating point type we support is 64bit, native and Java double.

But there exists an additional precision type built into the language, long double which is supposed to be at least as precise as double. See more on Wikipedia

We should support this native type by allowing users to map native long double to Java's BigDecimal which is the standard way of storing floating point numbers that cannot fit into double. This may need an annotation from users to help JNR-FFI know exactly what is being desired. An example mapping would look like this:

C function:

typedef long double ldouble;
ldouble ret_ldouble(ldouble d);

Java:

public @long_double BigDecimal ret_ldouble(@long_double BigDecimal d);

This may be much more difficult than it initially seems for multiple different reasons:

  • There is no standard size for long double, the only requirement is it is at least as precise as double, on x86it is 80-bits except using Microsoft Visual C++ where it is the same as double (of course 🤦), on aarch64 and powerpc it is 128 bits on GNU/Linux, See the Wikipedia page for more
  • We may need JNI support, meaning we may need to add new functionality into jnr-jffi, this is a problem because it means we would need to recompile the JNI for each of the platforms we support and they are very many! I don't think this will be the case, but if it is, then we can't proceed with this, since it is way too many platforms (including many obscure and rare ones) to build for.
  • We would also need to implement (or at least add) this for Structs, Unions and Pointers, since they can contain this native type.

This might be more work than it's worth, but I think it's worth at least investigating and logging the findings for when one day this may be more worthwhile pursuing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant