Re: FW: Two technical questions on IEEE Std 754-2008
From: Charles Stevens <charles.stevens@xxxxxxxx>
To: IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>
Subject: FW: Two technical questions on IEEE Std 754-2008
Date: Wed, 23 Feb 2011 14:33:26 -0700
. . .
While it is possible to distinguish between the encodings of two decimal128=
items WITHIN the implementation=2C it is not possible to distinguish which=
encoding it is when it comes from OUTSIDE the implementation. That's the =
If you've got=2C say=2C an 80-byte record on a reel-to-reel tape=2C the tap=
e's been written somewhere else=2C it's got a decimal128 item taking up the=
last 16 bytes of that record=2C with the first 64 bytes taken up with mean=
ingful and valid information=2C there's nowhere to put an indication of wha=
t encoding was used to develop the numeric value in that record. We can't =
"tag" data with the encoding if we don't know where it came from. The guy =
who built it can't tag it either=2C because it's already written. The impl=
ementor on the machine reading the tape can't tag it because he doesn't kno=
w what the intent of the guy who wrote the tape was. The same applies to i=
nformation that may come in as parameters from "outside sources" (including=
the internet) outside the implementor's complete control.
. . .
On this one point only:
I recognise the need to service the dusty decks of
this world. Especially for a language like Cobol.
But you are at a unique point in the history of this
issue. No such tapes exist today. And won't for a
short time to come. So, today only, this problem can
be fixed by REQUIRING such data to identify itself.
If you wait until the next revision of Cobol that
will no longer be possible.
Consider this also in your concerns about how to
approach solving this problem. Waiting may rob you
of your only reasonable solution.
Just an observation...