Re: [Cobolforgcc-devel] MOVE subroutine in UNSTRING

[Steven O. E. <so...@so...>]

Tim,

Fair enough.  I propose yet another parameter containing the picture
character string for each receiving area.  

As Bill suggests, "P" and "0" can be disallowed for now, and for the
immediate purposes, I would disallow "V" and anything else except
{X,S,(,),0,1,2,3,4,5,6,7,8,9}.  "0" would be allowed only within
parentheses.  The receiving area could then be text, signed integer, or
unsigned integer.  I think that would make the UNSTRING routine
"seaworthy" for the time being.

Receiving areas will be USAGE DISPLAY because:

6.27.3 Syntax Rules 

(3) Identifier-4 may be described as either the category alphabetic,
    alphanumeric, or numeric (except that the symbol 'P' may not be
    used in the PICTURE character-string), and must be described
    implicitly or explicitly, as USAGE IS DISPLAY. 

There is one other thing, though.  In the set of usage flags currently
defined in cobr_temp_config.h, there is "SIGN IS TRAILING SEPARATE", but
no "SIGN IS LEADING SEPARATE".  This simplifies the problem.  But will
the COBOLforGCC implementation always require a separate sign to be
trailing, or will this be changed in the future?


	Steven


Tim Josling wrote:
> 
> Steven,
> 
> How about this:
> 
> - add a parameter for each receiving area, to specify the type
> per cobr_type enum in cobr_temp_config.h.
> - add a parameter for each receiving area to say if it is left
> justified or right justified (eg a COB_UINT32 which has value 1
> if right justified
> - hand code to cater only for the type cobrTypeText which is pic
> x(n) and also cater for right justified.
> - add assert(type_parm==cobrTypeText);
> so that it will crash if someone passes something it can't
> handle.
> 
> Or some other scheme, as long as it is simple and uses the types
> in cobr_temp_config.h
> 
> Later on once all the move variants are supported we can add code
> to call the appropriate routine.
> 
> Regards,
> Tim Josling
> 
> "Steven O. Ellis" wrote:
> >
> > Tim,
> >
> > STRING is OK.  The following rule disallows a right-justified receiving
> > item.  Identifier-3 is the receiving item.
> >
> > 6.25.3 Syntax rules
> >
> > 4) Identifier-3 must not represent an edited data item and must
> > not be described with the JUSTIFIED clause.
> >
> > However, for UNSTRING, the receiving area may be numeric.   UNSTRING
> > General Rule 6.27.3 (2) refers to the sending area, not the receiving
> > area.  I do believe there is the potential for a numeric move per
> > General Rule 6.27.4 (13c), quoted below.  And per MOVE General Rule
> > 6.19.4 (4b), when the receiving area is numeric and the sending area is
> > alphanumeric, "data is moved as if the sending operand were described as
> > an unsigned numeric integer."
> >
> > This is not something that needs to be resolved at once, but I am
> > thinking that the final version of UNSTRING is going to have to be able
> > to handle a more sophisticated move.
> >
> > Steven
> >