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 · 4 comments
Open

Missing c_float and c_double types #3999

momumi opened this issue Dec 29, 2019 · 4 comments
Labels
Milestone

Comments

@momumi
Copy link
Contributor

@momumi 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 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

This comment has been minimized.

Copy link
Member

@andrewrk andrewrk commented Dec 31, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@momumi 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

This comment has been minimized.

Copy link
Contributor

@shawnl 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

This comment has been minimized.

Copy link
Contributor Author

@momumi 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

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

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.