The g77stripcard program handles removing content beyond
column 72 (adjustable via a command-line option),
optionally warning about that content being something other
than trailing whitespace or Fortran commentary.
This program is needed because lex.c doesn't pay attention
to maximum line lengths at all, to make it easier to maintain,
as well as faster (for sources that don't depend on the maximum
column length vis-a-vis trailing non-blank non-commentary content).
Just how this program will be run--whether automatically for
old source (perhaps as the default for .f files?)--is not
yet determined.
In the meantime, it might as well be implemented as a typical UNIX pipe.
It should accept a -fline-length-n option,
with the default line length set to 72.
When the text it strips off the end of a line is not blank
(not spaces and tabs),
it should insert an additional comment line
(beginning with !,
so it works for both fixed-form and free-form files)
containing the text,
following the stripped line.
The inserted comment should have a prefix of some kind,
TBD, that distinguishes the comment as representing stripped text.
Users could use that to sed out such lines, if they wished--it
seems silly to provide a command-line option to delete information
when it can be so easily filtered out by another program.
(This inserted comment should be designed to "fit in" well
with whatever the Fortran community is using these days for
preprocessor, translator, and other such products, like OpenMP.
What that's all about, and how g77 can elegantly fit its
special comment conventions into it all, is TBD as well.
We don't want to reinvent the wheel here, but if there turn out
to be too many conflicting conventions, we might have to invent
one that looks nothing like the others, but which offers their
host products a better infrastructure in which to fit and coexist
peacefully.)
g77stripcard probably shouldn't do any tab expansion or other
fancy stuff.
People can use expand or other pre-filtering if they like.
The idea here is to keep each stage quite simple, while providing
excellent performance for "normal" code.
(Code with junk beyond column 73 is not really "normal", as it comes from a card-punch heritage, and will be increasingly hard for tomorrow's Fortran programmers to read.)