[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Two technical questions on IEEE Std 754-2008

With regard to Endianness:
from the COBOL standard's point of view, it's a red herring.
May not be for the implementor, but it is for the standard.

That's what I expected.  What I don't understand is why the
BID/DPD distinction can't be treated the same way.  As I said,
I'm trying to SIMPLIFY your job.

The original issue that I raised had to do with "What do we do if a datum is
described as decimal64 (implicitly DPD), and it actually contains BID?"  As
was pointed out more than once, you have to know what you're dealing with.
If it doesn't match what you've been told it is, the results are undefined,
and that's on the backs of the sender.  But if it's been described to you
as decimal64 BID, it's a Really Bad Idea to treat it as decimal64 DPD.

My point is that IF the BID/DPD distinction was treated like Endianness,
this issue would not even arise.  Type "decimal64" would NOT imply DPD,
just as type "binary64" does not imply Big-Endian.  Indeed, at the
encoding level there are two forms of binary64 and four of decimal64.
The fact that Endianness is usually swept under the rug (including in
IEEE 754-2008) is just because the issue is so trivial it does not need
a detailed description, unlike the BID vs DPD distinction -- but those
who implement runtime environments and language processors (compilers
or interpreters) do have to deal with it.

Again, I'm waiting for an explanation of how COBOL implementations deal
with the hidden encoding issues of character set and Endianness when it
comes to importing or exporting records.

Look at other languages that have tackled DFP.  They don't care about
BID vs DPD, just as they don't (at the language level) care about
Endianness.  In some languages, programs that explicitly deal with
external data may use library functions (or macros, to avoid function
calls when the operation is null and inlining is not supported) to
convert between external and native formats, e.g. the ntoh() and
hton() families in C to convert between Netork (Big-Endian) and Host
(native) format.  In other languages this may be handled entirely
under the cover, as is apparently the case for Endianness in COBOL.

Be very careful what you include in a language spec, because it will
be with you for a long time.  Underspecification is bad, but so it

Look, I have no beef in this.  IBM would probably be happy if all DFP
was encoded in what is friendliest to its P and Z hardware (i.e. DPD),
but I'm writing this as a personal opinion.  I'm saddened when mistakes
are made that could have been avoided if action had been taken earlier.

---Sent: 2011-02-25 18:07:24 UTC

754 | revision | FAQ | references | list archive