Some more items that would make
g77 more reliable
and easier to maintain:
expr.cdo it. (Exceptions might include things like diagnosing
PARAMETER--if it seems important to preserve the left-to-right-in-source order of production of diagnostics.)
-Dto establish requirements to achieve desired implementation dialect via
opANYin more places in
ste.c, and get rid of the
opCONVERT(opANY)kludge (after determining if there is indeed no real need for it).
bad.defmessages and their references in the code, to make sure calls are consistent with message templates.
&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?
_, though it'd be ugly and probably not worth the time).
proj.hand use them throughout
g77source code (especially in the definitions of access macros in
.hfiles) so they can be tailored to catch code writing into a
RETURNS()or reading from a
constand other such stuff.
ffebld_newcalls (those outside of
ffeexpr.cor inside but invoked via paths not involving
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.
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.)
EQUIVALENCEsomething due to alignment/mismatch or other problems--they end up without
ffestoragobjects, 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.