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.

Go to the first, previous, next, last section, table of contents.