Re: [Cobolforgcc-devel] UNSTRING Function Argument Values

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

Tim,

I have gone back to the idea of inner loops and thought about it a bit.
It seems to me that keeping track of the all the possibilities, some of
which might involve backtracking, might make the "loops solution"
just as complex as the linear solution I am working on.  I'll know
more when I run a few tests.

There a couple more questions regarding the function arguments
that I would like to get resolved before I spend too much more time
setting up the tests.

1)  Many options to UNSTRING are optional.  I have assumed in
    my coding that if an array of options, like "count_in_array" or
    "delimiter_in_array" is not used, then it is passed as a NULL
    pointer.  Is that how you understand it?

    Further, that if even one such field is used, then the array
    must be fully instantiated, that is, space must be allocated on
    the heap for the entire array, whether it is all needed or not,
    and when UNSTRING returns, the core compiler will simply
    pick out those elements that were actually specified by the
    COBOL programmer.

    For example, if the fifth target item is the only one that has
    COUNT IN specified, then the count_in_array argument to
    UNSTRING must be a pointer to a space big enough for the
    whole array.   If no target items have COUNT IN, then the
    count_in_array argument can be NULL.

    That is, if the count_in_array or the delimiter_in_array
    arguments are NULL, the UNSTRING function ignores them.
    If not, UNSTRING populates all of the elements and the
    core compiler can pick out the ones it needs.

2)  If the above seems right to you, then I wonder if the
    TALLYING field should be made a pointer than can be
    NULL if the field is not specified.

3)  I am assuming that the POINTER field is always going
    to be passed (as an int) to the UNSTRING function.

Thanks,

    Steven


Tim Josling wrote:

> Steven,
>
> I tend to think the best way might be to do it in a quite simple manner
> ie with the inner loops. Most unstrings I have seen have only had one or
> a small number of short delimiters. The Extreme Programming term for this
> is 'The Simplest Thing That Could Possibly Work'.
>
> As far as the data types go, the receiving area must be display but can
> be numeric (with all the usual overpunching stuff) and can be right
> justified as well as left justified.
>
> The core compiler does not support numeric display or right justified
> yet, so support for these is not urgent and there is no runtime routine
> to do it yet. My thought would be to support right justified in your own
> code. When I add right justified to the compiler I will pull that code
> out into its own routine. But I would just put an abort in if you get a
> numeric display format output item. We could add that support later on
> quite easily, as a call to the appropriate move routine.
>
> My preference always is to get something working and then refine it,
> rather than solve all the problems at once. But go with the approach you
> are most comfortable with.
>
> Tim Josling
>
> "Steven O. Ellis" wrote:
>
> > Tim,
> >
> > I set up several designs for test cases and coded a few of them.
> > Then I decided to go back and actually start coding the UNSTRING
> > routine.  Whew!  Nontrivial.
> >
> > The problem lies in preventing excessive looping when the user
> > (COBOL programmer) specifies several, long delimiters.  There is
> > a risk of having to set up the problem all over again, one byte at a
> > time, when several delimiters are matching up to a point and then
> > failing, causing the algorithm has to have to backtrack over and over.
> >
> > In order to handle this, I am exploring the Knuth-Morris-Pratt
> > algorithm as discussed in "Introduction to Algorithms", by
> > Cormen, Leiserson, and Rivest (c) 1990 MIT.  I have this coded
> > but not yet tested.  A slight modification to the KMP algorithm
> > would seem to allow the delimiter-check to ride along the source
> > field in a linear fashion, without backtracking, even with multiple
> > length delimiters.
> >
> > This brings up a few questions.   I have no compiler-writing
> > training, and I'm  not familiar with your overall design, so perhaps
> > we can discuss this.
> >
> > We talked about MOVE awhile back but I don't think I ever
> > directly asked this: can UNSTRING call the
> > MOVE routine, or must it be coded within UNSTRING itself?  If
> > MOVE has been coded and is available, I would like to have the
> > source and headers.  If not coded but the call is OK, I will put in
> > a temporary function.  If the call is not OK, I will code the move
> > into the UNSTRING function itself.
> >
> > Speaking of function calls, is UNSTRING allowed to call another
> > function at all?  The KMP algorithm is best implemented as two
> > functions.  One I am coding into UNSTRING itself, but the initial
> > setup should be done by a function called by UNSTRING.
> > Is this OK?
> >
> > If it is OK to use a separate function for setting up the algorithm,
> > then I have another question about how the compiler deals with
> > this, but I'll wait until I hear back from you.
> >
> > Steven
> >
> > _______________________________________________
> > Cobolforgcc-devel mailing list
> > Cob...@li...
> > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel