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

Missing c_float and c_double types #3999

Open
momumi opened this issue Dec 29, 2019 · 6 comments
Open

Missing c_float and c_double types #3999

momumi opened this issue Dec 29, 2019 · 6 comments
Labels
docs proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@momumi
Copy link
Contributor

momumi commented Dec 29, 2019

Zig doesn't provide c_float and c_double types. C doesn't fully guarantee how the float and double types are implemented, so shouldn't zig provide types for them instead of relying on f32 and f64? If there is a reason for why they are omitted, it should probably be added to the documentation about floats and C interop.

@andrewrk andrewrk added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Dec 31, 2019
@andrewrk andrewrk added this to the 0.7.0 milestone Dec 31, 2019
@andrewrk andrewrk added the docs label Dec 31, 2019
@andrewrk
Copy link
Member

I'd have to double check, but I believe I found in the C spec that it defines float to be IEEE-754-2008 binary32 and double to be IEEE-754-2008 binary64. So the types are not necessary because they are redundant with f32 and f64 in Zig.

I agree that the docs or at the very least FAQ should be updated with an explanation of this.

@momumi
Copy link
Contributor Author

momumi commented Jan 1, 2020

From K&R The C Programming Language A.4.2:

Any of single precision floating point ( float ), double precision floating
point ( double ), and extra precision floating point ( long double ) may be
synonymous, but the ones later in the list are at least as precise as those
before.

For example in avr-gcc float and double are both 32 bits.

Also according to the rust documentation for c_float:

the standard technically only guarantees that it be a floating-point number,
and it may have less precision than f32 or not follow the IEEE-754 standard at all

@shawnl
Copy link
Contributor

shawnl commented Jan 18, 2020

Also c_longdouble

Also c_char and c_uchar, however I get the argument that the C environment probably should be sane, which makes all of these suggestions a bit superfluous.

@momumi
Copy link
Contributor Author

momumi commented Jan 20, 2020

@shawnl there's a related issue for c_char #875. It's still relevant for modern stuff eg: Android NDK

@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 27, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 23, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
@alexrp
Copy link
Member

alexrp commented Jun 24, 2024

To make this a bit more concrete: RX microcontrollers (which are still in use and have maintained GCC and QEMU ports) have sizeof(float) = sizeof(double) = 4 by default in GCC because the hardware only supports single-precision. It can be changed to sizeof(double) = 8 but this is non-default and uses soft float for double. I do think Zig needs to be able to cope with this, and introducing c_float and c_double seems the natural way to do so.

Edit: The same is true for RL78 microcontrollers. The GCC port for RL78 was added in 2011.

There are also older architectures like VAX and PDP-11 that have weird, non-IEEE float formats, but I don't know if Zig needs to care about those. These architectures are more or less dead, and it doesn't seem to be popular to create non-IEEE float formats anymore.

@alexrp
Copy link
Member

alexrp commented Aug 24, 2024

@andrewrk just for the record, I'm volunteering to do the implementation work for this feature if approved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

4 participants