21.2.1 g77stripcard

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