Internal Xref - Comp fields data description error ??

[David Wall]

Recently - trying to understand how comp fields get stored I knocked up scratch program that had variable sized fields from 9 to 9(9) described using all the variations of comp.
Passing the file thru the Xref I believe I've found an error in how the field sizes are calculated:

Please refer to the attached file - xx which is an extract from
the Xref output of Cobc with reference to Numeric Field descriptions.

C5 thru C9s are all indicated as having a size of 4 which seems wrong to me.
C11 thru C19s are all indicated as having a size of 4 ????
C21 thru C29s are all indicated as having a size of 8 ????
C45 thru C49s are all indicated as having a size of 4 ????
C55 thru C59s are all indicated as having a size of 4 ????
Cn1 thru Cn9s - Cn7 should be 4 & Cn9 & Cn9s should be 5 - ????
Cx1 thru Cx9s - Cx7 should be 4 & Cx9 & Cx9s should be 5 - ????

ie: How do you get the contents of S9(17)v9(17) comp-2 into 8 characters.

[Ralph Linkletter]

Comp-1 is single precision floating point:
float 1.175494351 E - 38 3.402823466 E + 38 (4 bytes comp-1)

Comp-2 is double precision floating point:
double 2.2250738585072014 E - 308 1.7976931348623158 E + 308 (8 bytes comp-2)

Mantissa scale:
float exponent 8 bits mantissa 23 bits
double exponent 11 bits mantissa 52 bits

Did you actually mean a floating point qualifier ? (comp-2)

Are you referring to the precision of the mantissa ?

Ralph

[David Wall]

No Ralph, I was just commenting on the number of bytes the Xref indicated were used for each field. I'm now 73 and am please to say I've 'NEVER' used a floating point number - and I ain't about to start now :)

OK - I'll ignore the comp-1 & comp-2 displays - but that doesn't cover what still appear to be errors in the comp, comp-4, comp-5, comp-n & comp-x type fields.

And we haven't gone into decimal places yet.

[Simon Sobisch]

As Ralph said USAGE COMP-1 commonly defines an internal float and USAGE COMP-2 an internal double floating-point binary, so the sizes are "fixed" and don't depend on the PICTURE but on the underlying system (commonly 4 and 8 bytes).
If you use those it is much better to use the standard ones (COBOL 2014): FLOAT-SHORT and FLOAT-LONG - and for those "a PICTURE clause should not be specified".
Note that there are other extensions, for example ACU's FLOAT and DOUBLE and also other definitions of COMP-1 which also can mean to be a SIGNED-SHORT depending on dialect flags.

The decimal places you could specify with COMP-1/COMP-2 (at least in some dialects) are used for the display (or should be), the value actually contained within that item may have the right accuracy or not depending on the system used and often are not "binary compatible" (writing + reading this to a file without editing is a bad idea).
To display in a debugger just MOVE the values to USAGE DISPLAY ones with the same PICTURE - or the default one which you see in the symbol listing, a conversion back works the same (thought it might not create the same binary value).
Note: with GnuCOBOL (definitely not with all other COBOL environments) a floating-point comparision has a tolarance to cater for differences in accuracy and differences between displaying a value and assigning the displayed one (and then re-display and see a slightly different version - on some systems).

Similar the actual implementation of BINARY/COMP/COMP-4 may differ on other environments - for GnuCOBOL those three are identical.

The sizes of the COMP fields are related to -fbinary-size (and the byte order depending on -fbinary-byteorder, the symbol listing shows what is used for the specific compile.

One thing missing in your test code: many compilers allow to specify the byte-size with COMP-X and COMP-5 by using an alphanumeric picture.