[Cobolforgcc-devel] Runtime routines - confused

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

(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.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> 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.
> 
> 2.  Is the "flags" argument in the cobr_display() intended only for sign
> and over punch usage?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 3.  Should the same flags be used for cobr_editMove() and
> cobr_display()?
> 
> 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().
> 
> 5.  Ready for the Olympics?
> 
> Thanks Much - Ted Seward