[Cobolforgcc-devel] FW: MOVE 2002

[William M. K. <wm...@ix...>]

Tim,
 Sorry for not getting back to you sooner on this.  I believe that you are
correct that this is "underspecified" in the FCD.  There is no way to
determine HOW MANY "leading zeroes" are in the USAGE BINARY-LONG item before
its "conversion" which makes the "alignment rules" impossible to figure out.
It is clear that the "signed" phrase is "ignored" - but that doesn't really
answer your question.

I plan on including this in my (last) Public Review comment - but you may
want to include it as well.

P.S.  I haven't checked it - but your "VALUE" clause for V1 may not be
"conforming".  I can't remember if you can have an unsigned VALUE clause for
a USAGE BINARY-LONG SIGNED data item or not.  However, that wouldn't
"change" the impact of your question.

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Tuesday, April 03, 2001 3:48 AM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] MOVE 2002
>
>
> Bill,
>
> The problem I have is that is says (p484 s14.10.24.3) "conversion
> of the sending operand to the internal representation takes
> place". That's good, but what sort of conversion?
>
> 01   v1 usage binary-long signed value 123.
> 01   v2 pic x(5).
> move v1 to v2.
>
> There are many ways to convert a binary number to an alphanumeric
> (see the C function printf for a list).
>
> The result could be:
>
> "123bb" (b=blank)
> or "00123"
> or "00000" (with the remaining digits 00123 truncated on the
> right, on the basis that the 32 bit integer gets converted to a
> 10 digit string because it needs that many characters to hold 32
> bit numbers in general).
>
> Pre-COBOL 2002, the problem probably did not exist as everything
> has a PIC, so the number of characters is defined.
>
> Reading the standard again, I find that the reverse situation
> *is* covered OK (ie move pic x(n) to binary-*). So moving "123"
> to a binary-char gets you 123, whereas moving "  123" gets you an
> error.
>