[bug #59993] tbl: save .hlm register correctly

[G. Branden Robinson]

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

                 Summary: tbl: save .hlm register correctly
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Wed 03 Feb 2021 05:10:23 AM UTC
                Category: Preprocessor tbl
                Severity: 3 - Normal
              Item Group: Warning/Suspicious behaviour
                  Status: In Progress
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

Seen in a recent generation of the groff man pages:


troff: backtrace: 'groff_man_style.7':92: macro '3init'
troff: backtrace: file 'groff_man_style.7':145
troff: groff_man_style.7:145: error: numeric overflow; term > 2147483639
troff: backtrace: 'groff_mm.7':3790: macro '3init'
troff: backtrace: file 'groff_mm.7':3812
troff: groff_mm.7:3812: error: numeric overflow; term > 2147483639


(The part from the semicolon forward in each error diagnostics is a local
change I introduced while researching this issue.)

The above wrongness does not cause any formatting problems but it is
surprising.  It turns out to arise from a rookie mistake I made in commit
cee547e8839a82f8b21b2859a9370fd74f9793f3 on 30 January.


        ".nr " SAVED_HYPHENATION_MAX_LINES_REG " \\n[.hlm]\n"


This may look inoffensive enough, but '-1' is a valid value of \n[.hlm]
(meaning "unlimited").

The above C-preprocesses and ultimately interpolates to:


.nr 3hyphmaxlines -1


...which still may not look like a problem.  However:

(1) The above is placed in the generated *roff preamble of every table in a
*roff document, and

(2) tbl does not remove the registers it sets up in each chunk of generated
table output (roughly, every .TS/.TE block it processes).

...which STILL may not seem like a problem, even to witches who cite the deep
magic.  But watch this:


$ groff
.nr a -1
.tm \na
-1
.nr a -1
.tm \na
-2


The leading '-' is not interpreted as an algebraic sign but as an
decrementation amount.  You may still wonder how the hell we got to a 32-bit
integer overflow in a practical document, but further inspection will reveal a
Persian chessboard problem.  When I instrumented the problematic groff_mm.7
file after preprocessing it with tbl, I got this.


$ ./build/test-groff -z -Tutf8 -mandoc mm.7
3hyphmaxlines is -1
3hyphmaxlines is -2
3hyphmaxlines is -4
3hyphmaxlines is -8
3hyphmaxlines is -16
3hyphmaxlines is -32
3hyphmaxlines is -64
3hyphmaxlines is -128
3hyphmaxlines is -256
3hyphmaxlines is -512
3hyphmaxlines is -1024
3hyphmaxlines is -2048
3hyphmaxlines is -4096
3hyphmaxlines is -8192
3hyphmaxlines is -16384
3hyphmaxlines is -32768
3hyphmaxlines is -65536
3hyphmaxlines is -131072
3hyphmaxlines is -262144
3hyphmaxlines is -524288
3hyphmaxlines is -1048576
3hyphmaxlines is -2097152
3hyphmaxlines is -4194304
3hyphmaxlines is -8388608
3hyphmaxlines is -16777216
3hyphmaxlines is -33554432
3hyphmaxlines is -67108864
3hyphmaxlines is -134217728
3hyphmaxlines is -268435456
3hyphmaxlines is -536870912
3hyphmaxlines is -1073741824
3hyphmaxlines is -2147483648
troff: backtrace: './build/contrib/mm/groff_mm.7':3794: macro '3init'
troff: backtrace: file './build/contrib/mm/groff_mm.7':3805
troff: ./build/contrib/mm/groff_mm.7:3805: error: numeric overflow; term >
2147483639


No bueno.




    _______________________________________________________

Reply to this item at:

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

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