root/trunk/fcode-utils-devel/TODO

fcode-utils/detok/decode.c
   Line 46:
 *
 *      Still to be done:
 *          Handling of indent-level is not correct.  Branches should
 *              balance with their resolvers; constructs like do..loop
 *              case/of/endof/endcase are a few major examples.
 *          This will be tricky; the rules need to be carefully thought
 *              out, and the implementation might be more complex than
 *              at first meets the eye...
 *

   Line 280:
 *
 *      Still to be done:
 *          More sophisticated error-checking for invalid offsets.  Look
 *              at the type of branch, and what should be expected in the
 *              vicinity of the destination.  (This might be best served
 *              by a separate routine).
 *         This might also help with handling the indent-level correctly...
 *              Also, if indentation were to be handled in this routine,
 *              there would be no need to return the value of the offset.
 *


fcode-utils/detok/pcihdr.c
   Line 67:
 *
 *      Still to be done:
 *          Print (as remarks) full descriptions of headers' fields
 *          Error check for wrong "Format"
 *          Skip past non-FCode blocks, thru multiple data-blocks
 *          Recognize PCI header in unexpected place or out-of-place
 *

   Line 130:
 *
 *      Still to be done:
 *          Error-check; look for inconsistencies:
 *              Return a Negative Number if data-stream appears to be a PCI
 *              header, but has erroneous or inconsistent sub-field contents.
 *              Value and meaning of the Negative Number yet to be defined.
 *

   Line 188:
 *
 *      Still to be done:
 *          Error-check; look for wrong "Code Type" or other inconsistencies:
 *              Return a Negative Number if data-stream appears to be a
 *              valid PCI Data Structure, but has erroneous or inconsistent
 *              sub-field contents.
 *              Value and meaning of the Negative Number yet to be defined.
 *          Skip past non-FCode data-blocks, even multiple blocks
 *

   Line 364:
 *
 *      Still to be done:
 *          Handle error cases.  At present, neither  is_pci_header()
 *              nor  is_pci_data_struct()  returns a negative number,
 *              but when they are modified to do so, we must handle it.
 *

   Line 442:
 *
 *      Still to be done:
 *          Come up with something more elegant for non-zero filler.
 *


fcode-utils/detok/printformats.c
   Line 74:
 *
 *      Still to be done:
 *          Define a routine, call it  PrintComment , to print the given
 *              string surrounded by open-paren-space ... space-close-paren
 *          Define a single central routine, call it  safe_malloc ,
 *              to do the test for null and print "No Memory" and exit.
 *          Define a single central routine, call it  PrintError , to:
 *              Print the given error message
 *              Show the input file and line number
 *              Collect error-flags for failure-exit at end of operation.
 *


fcode-utils/toke/devnode.c
   Line 67:
 *
 *      Still to be done:
 *          Add a pair of fields to the data-structure for the Input File and
 *              Line Number where "finish-device" occurred.  When a device-node
 *              is "finish"ed, do not delete it, but instead fill in those
 *              fields and the move the node to a separate linked-list.
 *          When looking whether a word exists in an ancestor-node, also
 *              check whether it was in a device-node that was finished and
 *              print both where it was started and where it was finished.
 *


fcode-utils/toke/emit.c
   Line 34:
 *
 *      Still to be done:
 *          Re-arrange routine and variable locations to clarify the
 *              functions of this file and its companion, stream.c 
 *          This file should be concerned primarily with management
 *              of the Outputs; stream.c should be primarily concerned
 *              with management of the Inputs.
 *          Hard to justify, pragmatically, but will make for easier
 *              maintainability down the proverbial road...
 *


fcode-utils/toke/flowcontrol.c
   Line 75:
 *
 *      Still to be done:
 *          Correct analysis of Return-Stack usage around Flow-Control
 *              constructs, including within Do-Loops or before Loop
 *              Elements like I and J or UNLOOP or LEAVE.
 *          Similarly, Return-Stack usage around IF ... ELSE ... THEN
 *              statements needs analysis.  For instance, the following:
 * 
 *          blablabla >R  yadayada IF  R> gubble ELSE flubble R>  THEN
 * 
 *              is, in fact, correct, while something like:
 * 
 *          blablabla >R  yadayada IF  R> gubble THEN
 * 
 *              is an error.
 * 
 *          Implementing an analysis that would be sufficiently accurate
 *              to justify reporting an ERROR with certainty (rather than
 *              a mere WARNING speculatively) would probably require full
 *              coordination with management of Flow-Control constructs,
 *              and so is noted here.
 *


fcode-utils/toke/macros.c
   Line 166:
 *
 *      Still to be done:
 *          If an error is encountered during Macro evaluation, display
 *              supplemental information giving the name of the Macro 
 *              being run, and the file and line number in which it was
 *              defined.
 *          This will require changes to the way user Macros are added
 *              and retained, and to the way error messages are displayed.
 *


fcode-utils/toke/nextfcode.c
   Line 90:
 *
 *      Still to be done:
 *          Detect and report when the Current Range stops overlapping
 *              one particular Range and starts overlapping another.
 *


fcode-utils/toke/scanner.c
   Line 1046:
 *
 *      Still to be done:
 *          Better protection against PC pointer-over-run past END.
 *              Currently, this works, but it's held together by threads:
 *              Because  init_stream  forces a null-byte at the end of
 *              the input buffer, parse_number() exits immediately upon
 *              encountering it.  This situation could be covered more
 *              robustly...
 *

   Line 2192:
 *
 *      Still to be done:
 *          Full detection of whether the Return-Stack has been cleared
 *              when required, including analysis of Return-Stack usage
 *              within Flow-Control constructs, and before Loop elements...
 *

   Line 2259:
 *
 *      Still to be done:
 *          Correct analysis of Return-Stack usage around Flow-Control
 *              constructs.  Consider, for instance, the following:
 * 
 *          blablabla >R  yadayada IF  R> gubble ELSE flubble R>  THEN
 * 
 *              It is, in fact, correct, but the present scheme would
 *              tag it as a possible error.  Conversely, something like:
 * 
 *          blablabla >R  yadayada IF  R> gubble THEN
 * 
 *              would not get tagged, even though it is actually an error.
 * 
 *          The current simple scheme also does not cover Return-Stack
 *              usage within Do-Loops or before Loop elements like I and
 *              J or UNLOOP or LEAVE.  Implementing something like that
 *              would probably need to be integrated in with Flow-Control
 *              constructs, and will be noted in  flowcontrol.c
 *

   Line 2323:
 *
 *      Still to be done:
 *          Correct analysis of Return-Stack usage...
 *

   Line 3299:
 *
 *      Still to be done:
 *          If the definer-name is not found, we might still look up
 *              the target name in the various vocabularies and use
 *              a phrase for those.  E.g., if it is a valid token,
 *              we could say it's defined as a "primitive".  (I'm
 *              not sure what we'd say about an FWord...)
 *

   Line 4617:
 *
 *      Still to be done:
 *          Correct analysis of Return-Stack usage within Do-Loops
 *              or before Loop Elements like I and J or UNLOOP or LEAVE.
 *


fcode-utils/toke/stream.c
   Line 60:
 *
 *      Still to be done:
 *          Re-arrange routine and variable locations to clarify the
 *              functions of this file and its companion, emit.c 
 *          This file should be concerned primarily with management
 *              of the Inputs; emit.c should be primarily concerned
 *              with management of the Outputs.
 *          Hard to justify, pragmatically, but will make for easier
 *              maintainability down the proverbial road...
 *

   Line 1070:
 *
 *      Still to be done:
 *          Set a flag when carr-ret has been replaced by space;
 *              when a string crosses a line, if this flag is set,
 *              issue a warning that an extra space has been inserted.
 *


fcode-utils/toke/toke.c
   Line 363:
 *
 *      Still to be done:
 *          Devise a syntax to allow the command-line to specify multiple
 *              input files together with an output file name for each.
 *          Currently, the syntax allows only one output file name to be
 *              specified; when multiple input file names are specified,
 *              the specification of an output file name is disallowed,
 *              and only the default output file names are permitted.
 *              While this works around the immediate problem, a more
 *              elegant solution could be devised...
 *


fcode-utils/toke/usersymbols.c
   Line 78:
 *
 *      Still to be done:
 *          Convert the handling of user-defined symbols to the T.I.C.
 *              data-structure and its support routines.  This should
 *              eliminate any further need of String-Substitution-type
 *              vocabularies.  User-defined symbols will, however, still
 *              need to be a separate vocabulary from the Global, because
 *              they are required to stay in effect for the duration of
 *              the entire batch of tokenizations...
 *          (Afterthought:  This is only true for user-defined symbols that
 *              were created on the command-line; if we ever allow symbols
 *              to be defined in the Source file, they should be as volatile
 *              as anything else that comes from a source file...
 *           Appending source-file-derived user-defined symbols to the Global
 *              Vocabulary could be a quasi-simple way to accomplish this.)
 *

   Line 246:
 *
 *      Still to be done:
 *          Hook-in this routine to the processing of:  [']  F[']  H#  FLOAD
 *              etc., and wherever else it might be needed or useful.
 *

   Line 316:
 *
 *      Still to be done:
 *          Space the duplicate-name notation evenly; line it up past
 *               the longest name-with-value.
 *