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 ffewheres 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.