Network IEEE 754 to Native Floats: which pack/unpack ops better?

[shenme]

In thread Extracting IEEE 754 floating point numbers are two working answers to my problem, that of converting network-order IEEE 754 float values to native float values on an Intel machine.   Although one of them

  $num = unpack "f", reverse $packed_num;

had occurred to me, the other one

  $float = unpack "f", pack "N", unpack "V", $data;

just 'feels' wrong.   Before finding that thread I had tried

  $float = unpack 'f', pack 'L', unpack 'N', $data;

which also works.

Now the fact is that on the Intel platforms pack 'N', unpack 'V', $data and pack 'L', unpack 'N', $data both accomplish the transformation from big-endian to little-endian byte order.   But it seems to me that I _should_ use 'N' first on the network-order 4-byte value, then force the 4-byte value to a native order 4-byte value, and only then convert to a native float value.   In this way the same code would work on non-Intel machines?

I guess I'm asking, which is the more pedant-proof answer?

[Roger]

Personally I think $float = unpack 'f', pack 'L', unpack 'N', $data; is a better solution. It is conforming to the standard, ie, it acknowledges that the input data is in network long format. It is more portable, although you assume that float is 32 bits long. Consider the packing and unpacking process -



 packing float as network long:
 +-----+    +-----------+    +------------+
 |float|--->|native long|--->|network long|
 +-----+    +-----------+    +------------+

 and unpacking network long back to float
 +------------+    +-----------+    +-----+
 |network long|--->|native long|--->|float|
 +------------+    +-----------+    +-----+

where perl takes care of translation between native long (big or little endian) and network long (always big endian), without you having to worry explicitly what is the underlying architecture.

The $float = unpack "f", pack "N", unpack "V", $data; and the $num = unpack "f", reverse $packed_num; solutions both assume that you are on a little endian machine, making you dependent to the underlying architecture.

Update: I have written the following test program to test this solution-


use strict;
use IO::File;

savefloat();  # <--- this is run from Sun E10000
readfloat();  # <--- this is run from Windows XP

sub savefloat {
  my $original_float = 1234.5678;
  my $network_long = pack 'N', unpack 'L', pack 'f', $original_float;
  my $f = new IO::File "NetworkLong.txt", "w";
  print $f $network_long, "\n";
}

sub readfloat {
  my $f = new IO::File "NetworkLong.txt", "r";
  chomp(my $network_long = <$f>);
  my $float = unpack 'f', pack 'L', unpack 'N', $network_long;
  printf "%0.4f\n", $float;
}

Two separate tests were conducted -

Test 1


On SUN: float->network_long->disk
On WindowsXP: disk->network_long->float

Test 2


On WindowsXP: float->network_long->disk
On SUN: disk->network_long->float

I got the same result in both test 1 and test 2. This proves that the particular packing method worked cross-platform on both Sun and WindowsXP, which are big endian and little endian platforms respectively.

[shenme]

There are at least two assumptions in my problem description regarding bit length.   First is that the native floating point format is indeed IEEE 754 conformant.   If so, a single-precision IEEE 754 value is 32 bits and the 'f' op will eat 4 bytes.   The second assumption, however, is a bit more uncertain.   While the 'L' op is defined as 32 bits, the 'N' op is defined as simply "an unsigned long".   Oh, wait, does the comment in perlfunc,

(These 'shorts' and 'longs' are _exactly_ 16 bits and _exactly_ 32 bits, respectively.)

apply to all four of the ops n, N, v, V grouped together?   (doh!)   Then we're good throughout using 32 bits (4 bytes), as long as everybody uses the IEEE format.

Thank you very much for testing on an other-endian system.   I so easily get cross-eyed with pack/unpack - it's nice to know sometimes I do get it!

[Stevie-O]

The reason the middle one:

$float = unpack "f", pack "N", unpack "V", $data;

feels wrong is probably because it is wrong. You have a network-order value that you need to convert to host-order value; I'll explain this backwards, as that's how perl has to process it.

unpack "V", $data;

This treats the data as if it were in Little-endian order (which is it is not) and turns it into a 32-bit integer.

pack "N", $data;

This packs the data into a string in Big-endian (network) order. This is also wrong, because you now are using it on a little-endian machine.

This is one of those few cases where two wrongs *do* make a right; these operations are done in the wrong order, but the net effect is the same (which is why it works).

Your last suggestion,

 pack 'L', unpack 'N', $data

is the most correct version. The unpack('N') unpacks the number as if it were a 32-bit value in network byte order (which it is), and the pack('L') re-packs the number as a 32-bit value in host byte order (which it is).