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.