Open momumi opened 4 years ago
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.
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
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.
@shawnl there's a related issue for c_char
#875. It's still relevant for modern stuff eg: Android NDK
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.
@andrewrk just for the record, I'm volunteering to do the implementation work for this feature if approved.
Zig doesn't provide
c_float
andc_double
types. C doesn't fully guarantee how thefloat
anddouble
types are implemented, so shouldn't zig provide types for them instead of relying onf32
andf64
? If there is a reason for why they are omitted, it should probably be added to the documentation about floats and C interop.