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

sizeof(double) is not guaranteed to be 64bits #37

Closed
mickjc750 opened this issue Aug 29, 2021 · 1 comment
Closed

sizeof(double) is not guaranteed to be 64bits #37

mickjc750 opened this issue Aug 29, 2021 · 1 comment
Assignees
Labels
resolved-on-develop A changeset fixing this issue has been commiutted to the development branch task

Comments

@mickjc750
Copy link

On AVR, and most likely some other 8-bit platforms, double is only 32bit.
This breaks %e and %g (but not %f).
Ideally, it would be nice to provide some kind of %e %g functionality when double is 32bit, perhaps with reduced precision.
At a minimum, a build error should occur if %e and or %g is enabled on these platforms.

@eyalroz
Copy link
Owner

eyalroz commented Sep 5, 2021

Hmm, you're right about the size. The standard apparently allows for smaller doubles.

How come it doesn't break %f, I wonder?

Anyway, I'll need to go over the code and see.

@eyalroz eyalroz self-assigned this Sep 5, 2021
@eyalroz eyalroz added the task label Sep 6, 2021
eyalroz added a commit that referenced this issue Sep 20, 2021
…(single-precision) rather than 64 bits (double precision).

* `double` type size is now checked indirectly via the number of mantissa digits.
* Now ensuring floating-point types are binary (as, technically, they could theoretically not be).
* Replaced some 64-bit-double-specific magic numbers with preprocessor-defined constants, depending on whether `double` is a 32 or 64-bit type.
* Now defining an unsigned integer type to correspond exactly to `double`.
* Some comment tweaks.
@eyalroz eyalroz added the resolved-on-develop A changeset fixing this issue has been commiutted to the development branch label Sep 20, 2021
eyalroz added a commit that referenced this issue Sep 27, 2021
…(single-precision) rather than 64 bits (double precision).

* `double` type size is now checked indirectly via the number of mantissa digits.
* Now ensuring floating-point types are binary (as, technically, they could theoretically not be).
* Replaced some 64-bit-double-specific magic numbers with preprocessor-defined constants, depending on whether `double` is a 32 or 64-bit type.
* Now defining an unsigned integer type to correspond exactly to `double`.
* Some comment tweaks.
@eyalroz eyalroz closed this as completed Oct 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolved-on-develop A changeset fixing this issue has been commiutted to the development branch task
Projects
None yet
Development

No branches or pull requests

2 participants