[bug #61100] [troff] do_request(): assertion failed: 'do_old_compatible_flag == -1'

[G. Branden Robinson]

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

                 Summary: [troff] do_request(): assertion failed:
'do_old_compatible_flag == -1'
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Wed 01 Sep 2021 08:59:57 AM UTC
                Category: Core
                Severity: 4 - Important
              Item Group: Crash/Not responding
                  Status: In Progress
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

Well, in attempting to "quickly" move a documentation item off my plate to
look into John Garnder's assertion failure report in bug #61089, I wrote a
little experiment to check my understanding of an issue and provoked an
entirely new assertion failure.

Good times, good times.


$ ./build/groff -Tutf8 -ww EXPERIMENTS/compatibility_mode_de.groff | cat -s
troff: ../src/roff/troff/input.cpp:2651: do_request(): assertion failed:
'do_old_compatible_flag == -1'
/home/branden/src/GIT/groff/build/groff: error: troff: Aborted (core dumped)


Input:

$ cat EXPERIMENTS/compatibility_mode_de.groff
.cp 1
.de xx
.do length a \\$1
.nr c 0
.do while \\nc<=\\na \{\
.  do ds s \\$1
.  do substring s 0 \\nc
.  do nop \\*s
.\}
\\$1 Saint-\['E]tienne (\\na)
..
.cp 0
.xx Caf\['e]


The assertion is one I added when implementing the new \n[.cp] feature last
year.  It _might_ be that I simply didn't anticipate this use case last year
and that I can remove the assertion without causing any harm.

Wouldn't that be nice?

I don't think I anticipated use of "do" within "de" within "cp 1", but in
trying to check my understanding of when special character escape sequences
get transformed into nodes, I blundered directly into my own land mine.

I have some thinking to do.




    _______________________________________________________

Reply to this item at:

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

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