This is not necessarily the current version of this TIP.
|Title:||New Format Codes for the [binary] Command|
|Version:||$Revision: 1.2 $|
Arjen Markus <arjen dot markus at wldelft dot nl>|
Torsten Reincke <reincke at typoscriptics dot de>
|Created:||Friday, 14 March 2003|
|Keywords:||IEEE, binary data|
This TIP proposes to add a set of new format codes to the [binary] command to enhance its ability to deal with especially non-native floating-point data. The assumption is that current limitations are due to the distinction between little-endian and big-endian storage of such data.
The current [binary] command can manipulate little-endian and big-endian integer data, but only native floating-point data. This means that binary data from other computer systems that use a different representation of floating-point data can not be directly handled.
The lack of format codes to handle "native" integer data means that one has to distinguish the current platform's byte ordering to be platform-independent, whenever the [binary] command is used.
Most current computer systems use either little-endian or big-endian byte order and the so-called IEEE representation for the exponent and mantissa. So, the main variation to deal with is the endian-ness.
Some popular file formats, like ESRI's ArcView shape files, use both types of byte order. It is difficult (though not impossible) to handle these files with the current set of format codes.
It should be noted that there is more variety among floating-point representation than just the byte order. This TIP will not solve this more general problem.
Format codes should be available to catch the two main varieties of byte ordering. There should, both for reasons of symmetry and for practical purposes, also be a full set to deal with "nat