If I save a float number to a file, then when load this number from file, in
any platform, I will have the same number?

I speak about C float.

I know this is not working with int and short but with float?

If it is not working what I can do?

Split the float into bytes is not a solution (in case of int is a solution)

Extract the mantissa and exponent.  They're just integers.

Or failing that output with a formated output function.

   float   realnums[COUNT];
   size_t  n;
   FILE   *fpw, *fpr;
...
   /* open suitable file(s) */
...
   n = fwrite(&realnums, sizeof float, COUNT, fpw);
   if (n != COUNT) handlewriteerror();
...
   n = fread(&realnums, sizeof float, COUNT, fpr);
   if (n != COUNT) eoforerroroccured();
...

but the file is likely to be useless if not used on the same breed
of machine with the same compiler.  Byte ordering, format, etc.
don't matter.  You can change float to any other type with
impunity as long as no pointers are involved.

#include <stddef.h>
#include <stdint.h>

union convert_float {
        float f;
        uint32_t i;

uint32_t
dec_uint32be(const unsigned char *src)
{
        return ((unsigned)src[0] << 24) | ((unsigned)src[1] << 16) |
           ((unsigned)src[2] << 8) | src[3];

Mike

Even more important, what if sizeof(float) != sizeof(unit32_t).

Specifically it does not guarantee that those 32 bits will occupy 4
bytes, because conforming C compilers are not required to provide 8
bit chars.  Specifically, for example, the Analog Devices SHARC has
CHAR_BIT 32 and sizeof(uint32_t) is 1.  The TI 28xx series has
CHAR_BIT 16 and sizeof(uint32_t) is 2.

And there is no guarantee, requirement, or even vague hint in the
standard that sizeof(uint32_t) == sizeof(float).  This happens to be
true on some platforms, but is by no means universal.

<math.h> in my really old reference book here declares these two
functions, which may be of some help:

    double frexp( double x, int * exponentPtr );
    double ldexp( double x, int exponent );

frexp() effectively extracts the fractional portion and exponent.
ldexp() effectively puts them back together again.

Caveats about the precision, of course.

You might be tempted to write the bit pattern of the fractional
portion, but you really shouldn't depend on the bit patterns of
floating point, even between different versions of the same compiler
on the same CPU. (You can get lucky, of course.) What you'd probably
want to do is something like this:

    double fractionalPart = frexp( valueToWrite, &exponentPart );
    int exponentPart, i;
    long accumulator = 0;
    char outbuff[ 6 ] = { 0 };
    for ( i = 0; i < 32; ++i )
    {   fractionalPart *= 2;
        accumulator <<= 1;
        if ( fractionalPart > 1 )
        {   accumulator |= 1;
            fractionalPart -= 1;
        }
    }
    outbuff[ 1 ] = (char) exponentPart;
    outbuff[ 0 ] = (char) exponentPart >> CHAR_BIT;
    for ( i = 5; i > 1; --i )
    {   outbuff[ i ] = (char) accumulator;
        /* Masking with UCHAR_MAX would be redundant, really. */
        accumulator >>= CHAR_BIT;
    }

Ant then write the six bytes out to a file opened for binary, etc.

On reading, you have to be careful with the sign bit bringing the
bytes in, of course. I personally prefer to use unsigned char for
things like this, but you still have to use casts.

No guarantees on the above. It is liable to drop bits and invent bits.
But there should be enough padding to avoid many implementation
issues. You get close to binary output, with the ability to read and
write most of the significant portion portably.

A little more care might suppress the invention of bits. I don't
really have time to go after that.

Restoring the fraction and doing doubles are left as an exercise.

Also, I just want to point out that even though the code is not portable
across all architectures the binary files it creates *are* portable
across architectures provided the {enc,dec} functions can be ported
(and with a little understanding there's a good possibility of that).

Of course in this case using the union over manually extracting the
mantissa and exponent is a no-brainer for the platforms that support it
(which is the popular majority: IA32, Sparc, etc).

Thanks,
Mike

Mike

You can probably avert this by declaring the union as volatile.

The other reason it's UB is because the resulting float value may be
illegal, and cause some kind of floating point trap.