(g77.info.gz) Internals Improvements

Info Catalog

(g77.info.gz) Internals Documentation

(g77.info.gz) Projects

(g77.info.gz) Better Diagnostics

 
 Internals Improvements
 ======================
 
    Some more items that would make `g77' more reliable and easier to
 maintain:
 
    * Generally make expression handling focus more on critical syntax
      stuff, leaving semantics to callers.  For example, anything a
      caller can check, semantically, let it do so, rather than having
      `expr.c' do it.  (Exceptions might include things like diagnosing
      `FOO(I--K:)=BAR' where `FOO' is a `PARAMETER'--if it seems
      important to preserve the left-to-right-in-source order of
      production of diagnostics.)
 
    * Come up with better naming conventions for `-D' to establish
      requirements to achieve desired implementation dialect via
      `proj.h'.
 
    * Clean up used tokens and `ffewhere's in `ffeglobal_terminate_1'.
 
    * Replace `sta.c' `outpooldisp' mechanism with `malloc_pool_use'.
 
    * Check for `opANY' in more places in `com.c', `std.c', and `ste.c',
      and get rid of the `opCONVERT(opANY)' kludge (after determining if
      there is indeed no real need for it).
 
    * Utility to read and check `bad.def' messages and their references
      in the code, to make sure calls are consistent with message
      templates.
 
    * Search and fix `&ffe...' and similar so that `ffe...ptr...' macros
      are available instead (a good argument for wishing this could have
      written all this stuff in C++, perhaps).  On the other hand, it's
      questionable whether this sort of improvement is really necessary,
      given the availability of tools such as Emacs and Perl, which make
      finding any address-taking of structure members easy enough?
 
    * Some modules truly export the member names of their structures
      (and the structures themselves), maybe fix this, and fix other
      modules that just appear to as well (by appending `_', though it'd
      be ugly and probably not worth the time).
 
    * Implement C macros `RETURNS(value)' and `SETS(something,value)' in
      `proj.h' and use them throughout `g77' source code (especially in
      the definitions of access macros in `.h' files) so they can be
      tailored to catch code writing into a `RETURNS()' or reading from
      a `SETS()'.
 
    * Decorate throughout with `const' and other such stuff.
 
    * All F90 notational derivations in the source code are still based
      on the S8.112 version of the draft standard.  Probably should
      update to the official standard, or put documentation of the rules
      as used in the code...uh...in the code.
 
    * Some `ffebld_new' calls (those outside of `ffeexpr.c' or inside
      but invoked via paths not involving `ffeexpr_lhs' or
      `ffeexpr_rhs') might be creating things in improper pools, leading
      to such things staying around too long or (doubtful, but possible
      and dangerous) not long enough.
 
    * Some `ffebld_list_new' (or whatever) calls might not be matched by
      `ffebld_list_bottom' (or whatever) calls, which might someday
      matter.  (It definitely is not a problem just yet.)
 
    * Probably not doing clean things when we fail to `EQUIVALENCE'
      something due to alignment/mismatch or other problems--they end up
      without `ffestorag' objects, so maybe the backend (and other parts
      of the front end) can notice that and handle like an `opANY' (do
      what it wants, just don't complain or crash).  Most of this seems
      to have been addressed by now, but a code review wouldn't hurt.
 

Info Catalog

(g77.info.gz) Internals Documentation

(g77.info.gz) Projects

(g77.info.gz) Better Diagnostics