[bug #60612] [man] FT register should get more validation

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?60612>

                 Summary: [man] FT register should get more validation
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Sun 16 May 2021 01:27:42 AM UTC
                Category: Macro - man
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

It is pretty easy to give the FT register values that will prevent the page
footer from being rendered.

When rendering to the terminal, if you give it a value x where approximately
-0.55v < x < -0, the footer will fail to print.

If you give FT a positive value x where x is less than the page position when
the page content is done rendering (the list of man pages in a "See also"
section, for example), then the footer will fail to print then, too.

Positive values seem pretty implausible for an FT setting.  We could reject
them, or at least warn.

Negative values are trickier to judge, but there is some sensible range we
could document.  I note that our TH macro sets a trap at -1i to queue a page
break (an-footer) no matter what the value of FT is.  It probably doesn't make
much sense to spring that trap after the one that actually writes the footer
(the rather stingily named "an-p-footer").  We could simply double the value
of FT and use that for the an-footer page location trap instead (and document
this).

None of this matters in continuous rendering mode (the default for nroff
devices, i.e., the terminal), where page location traps are not used, unless
the user sets -rcR=0 too see what can break, as I often do.

In any event, I feel FT is under-documented and very probably under-validated.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60612>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/