Thread: Portable floating point read/writes

Generally, the code

Code:

double x;
FILE *fp;

fwrite(x, 1, sizeof(x), fp);

...

fread(&x, 1, sizeof(x), fp);

will only work if the read and write is on the same platform. Floating point numbers are generally IEEE 754, but it's not guaranteed.

I've written routines which read and write in IEEE 754 format, portably. If the native format is not IEEE 754 then you necessarily lose a few bits of precision, but you get the closest representation possible on your native machine.

GitHub - MalcolmMcLean/ieee754: Ieee754 floating point routines, load and save ieee 754 even on non-ieee 754 hardware.

There's already a portable way to save and load almost anything. It's called ASCII. "1.543e-42" is automagically converted into a series of 4, 8 or 10 bytes( depending on what type of float you use ) for the IEEE-754. If your system uses a different floating-point representation or even a fixed-point one, it's automatically converted to the best of precision possible.

In other words, if you want portability you don't write/read binary files and only use text files.

Plenty of people do use text format, largely because of the floating point portability reason.

But you're not always in control of the format. RIFF files, for example, allow 32 bit floating
point audio. It has to be in IEEE 754, that's the file format specification. So the only way
to write a portable loader or saver is to use the functions.

Also, binary is usually a lot easier to parse than text. If we have an image, obviously we'll
need width and height. if they're in binary, we simply load as 16 bit little endian (or whatever
it is), sanity check, then make sure that the following rgb samples mach in number.
In fact on a big machine we can even do without the sanity check - if we don't have memory,
the allocation will fail.
What if the format is text? The values may not be numbers. They might have tabs instead of
spaces. It might be a number like 01234, or 100000000, even a string of digits a million long
(in a malicious exploit attempt). You can of course guard against all that, but it's hard and
must be carefully written. That's only integers, floating point numbers can have infinities,
nans, signed zeros, scientific form, no leading zero before the decimal point, spaces in
between the minus sign and the value.
The how do you know you've got machine precision? DBL_DIG does not give the number
of decimal places needed to reliably convert a value between text form and back without
loss of precision, confusingly, and many people don't know that.

Once you've got binary floating point loads and saves, it's often an easier way to go.