Re: [Cobolforgcc-devel] Runtime routines - confused

[Tim J. <te...@me...>]

Tim Josling wrote:
> 
> (forewarded by Tim Josling from initial email by Ted Seward)
> 
> > If you wish to pass these questions by some other people, that will be
> > fine as well.  I realize that you have a busy schedule as well, and
> > might not see these until later in the week.  I'll do the following on
> > Wednesday if I haven't heard from you, and then adjust the code based on
> > your answers:
> >
> > 1.  The cobr_editMove() currently uses an enumerated type where the
> > various sign and length values are part of the data type.  I'll leave
> > that in for now, just so you can have a working piece of code.  If you
> > decide, based on the questions below, that you would prefer hard coded
> > bit flags, e.g. #define name 0x00800000, I'll replace the enumerated
> > types with the bit types.
> >

I prefer enumerations for the basic type, flags for variants (eg
'has leading overpunched sign'). This way you can avoid having
too many enumerations, I think. But if the number of variants is
not too bad you could dispense with the flags. You have probably
thought about this a lot more than me.

> > 2.  I'll pass the bit flags to the cobr_display() routine, translate
> > them to the enumerated types, and then call cobr_editMove() to do all
> > the editing with display to standard out.  This implies that a simulated
> > Picture will be generated based on the precision flag.
> >

OK just don't forget about variable length fields. The PIC needs
to be considerably shorter than the actual data in such a case.

01 x1.
  02 x2 pic x occurs 1 to 10000000 depending nbr1.
01 nbr1 pic 9(9).

> > Questions:
> >
> > Until I can figure out how to get that modem to work on Linux, which
> > seems to be a requirement to upload to CVS, where do I E-mail to?

See my other email. You have three alternatives.

a) email me
b) email the development list
c) submit a patch using the sourceforge patch manager. To do this
you need to register with SF and have me add your userid to the
project. This doesn't require linux. 

> >
> > Now the real questions:  I held off one last time sending you the
> > editMove, since I was hoping to standardize the flags used by
> > cobr_editMove() & cobr_display().  These questions are all related to
> > that.  Part of my concern is looking at 4000+ lines of code using an
> > enumerated type, and now bit flags show up in the display.  I would
> > stand up for the enumerated types, but I actually see a great deal of
> > merit in the bit flags.
> >
> > 1.  Did you want the flags defined as an enum type or individual
> > #defines?

#defines 

probably or maybe as bit fields (as long as you have less than 32
it will fit in an int).

unsigned int flag1:1;

As you point out it is pushing what enum means to use enums for
flags.

> >
> > The enumerated type is nice because it groups things together and
> > automatically generates the assigned enumerated types.  It lacks in the
> > fact that compiler differences do not guarantee an integer type nor does
> > it permit such things as OR'ing flags together.  Type conflicts can also
> > be a problem if a given compiler does not define the usage of enumerated
> > type as an integer, e.g. strict type checking my cause an error message
> > trying to pass the value when the argument is defined as integer.
> >
> > The #define type is nice, but does require values to be hard coded,
> > perhaps causing problems if a typographical error replicates a given
> > value.  It is easier to OR these values together and the compiler will
> > permit them to be handed to an integer type.  They are tricky to use in
> > a switch statement if someone does OR the values together.

enums and bit fields are nicer in the debugger which does not
know about #defines

> >
> > 2.  Is the "flags" argument in the cobr_display() intended only for sign
> > and over punch usage?

That's all I thought of so far. Maybe character set (ascii ebcdic
unicode (this would be a two bit 'flag'), maybe not.

> >
> > The "flags" field in the prototype for the cobr_display() routine was
> > intended to pass arguments like trailing sign, and over punch.  This
> > does present a small problem since it could imply an over punched sign
> > for a binary type.  My books seem to indicate that only something with
> > usage DISPLAY is permitted to use the "S" picture element.

True so that some flag values would be invalid for some data
types. You can either assume they are valid (so a pic x(n) would
not even check the flag for leading overpunch), or check and
abort() if inconsistent flags are used. 

> >
> > I'm wondering if the "type" argument should carry this value as well.
> > Instead of just having types like:  display, packed, binary, etc., the
> > display type would be expanded to 5 types including the 4 special signed
> > versions:  display, displayLead, displayLeadSep, etc.
> >

My only concern here is an explosion of types

eg 

ebcdic numeric overpunched leading sign
ascii numeric overpunched leading sign....
unicode numeric overpunched leading sign

If I has enums like this I would probably convert to a basic type
plus flags.

> > On the other hand, if you are planing to add expanded functionality to
> > the DISPLAY routine, then it would be better to keep the flag field.
> > Perhaps special flags for languages, character sets, output to stderr
> > instead of stdout.

Yes, the number of possibilities can grow quickly. Although for
display upon I would  probably have another routine with an extra
parameter for the FILE*.

> >
> > 3.  Should the same flags be used for cobr_editMove() and
> > cobr_display()?

Preferably.

> >
> > 4.  Should an optional picture clause be passed to cobr_display()?  The
> > idea here is to have cobr_display() call the cobr_editMove function to
> > do the editing.  Maybe pass an optional picture and it would be used in
> > the call to cobr_display(), otherwise it would generate a picture and
> > then call cobr_display().
> >

I would prefer display to do a basic generic format, no need for
a PIC to be passed to it. You can generate a PIC internally and
pass to editMove and thereby reuse that code - that would be a
good idea.

> > 5.  Ready for the Olympics?
> >

You do not want them enywhere near you. Thanks to the olympics I
am having to fly home via Hong Kong due to contention for
bookings. All the con men descend upon your country, etc. 

General Comment
***************

We will no doubt rework this code a few times so it is probably
better to get it going 'reaonably well' and not worry too much
about getting it perfect first time. The open source model is
that antithesis of 'big design up front' - we will approach the
target in increments. I have rewritten parts of the compiler
several times.

Within reason of course. But there is probably lots of stuff we
don't know about - just do what makes sense for what we know
about and we will cross the other bridges when we come to them.

The compiler is not putting anything into the flags so far so in
no sense am I locked into using them.


Tim Josling