20.7 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.
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
important to preserve the left-to-right-in-source order of production
- Come up with better naming conventions for -D to establish requirements
to achieve desired implementation dialect via proj.h.
- Clean up used tokens and
- Replace sta.c
outpooldisp mechanism with
- 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)
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.
ffebld_new calls (those outside of ffeexpr.c or
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.)
- Probably not doing clean things when we fail to
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.