RE: Two technical questions on IEEE Std 754-2008
- For "clarification" - see below
Chuck Stevens wrote:
There's another advantage to this approach, Michel. Let's suppose
an application runs just fine on a BID-native machine, and let's
also suppose that the end user has a bunch of data on disk in BID
encoding. Let's further suppose that, for whatever reason, the
user decides to migrate to a DPD machine (exact same thing applies
I agree with everything Chuck wrote in that post.
I would like to point out however, again, that this reasoning ALSO
applies to the other two value-encoding issues, namely Endiannness and
Character coding. William Klein reported that some COBOL compilers do
support some form of Endianness tagging, and lamented the fact that
Ascii vs Ebcdic issues still remain.
-----end Original Message-snipped ----
Some compilers provide ways of declaring data to be either little- or
big-endian. They do NOT "tag" the data (nor do they expect the data to be
tagged). A program can "easily" (and with unpredictable results call
big-endian data as little-endian or vice versa.
Furthermore, I hope I did not sound like I was "lamenting" the lack of
self-describing data (for ASCII/EBCDIC issues). If the language HAD
originally been designed for that AND actual data were commonly stored and
shared in such a format, that probably would have been "nice".
Encoding issues ARE a problem when moving both programs and data from one
platform to another. However, this is an issue that COBOL (and I suspect
other language users) have dealt with for decades and will continue to do in
the future. To the extent that it is possible to define "industry standard"
encodings (e.g. 754 decimal floating point and Unicode/10646) data that may
or may not be "native" to the compiler/run-time environment, that provides
for additional portability. This does not (and will not) change the fact
that (for COBOL programmers at least) it is THEIR responsibility to define
the "view" of the data in a manner that actually reflects how it is encoded.