$ tex \\relax a\\end % => "texput.dvi" is written
$ dviasm texput.dvi >texput.dump
$ dviasm texput.dump -o texput.dump.dvi
The resulting "texput.dump.dvi" seems valid (at least for dvitype), but FNTDEF comes before BOP; I think such a DVI format is valid, as dvitype and most of the major DVI drivers accept it. However, there are some issues:
The dvispc's result "texput.dump.spc.dvi" does not contain FNTDEF before BOP or before the appearance of SETCHAR, so it's actually problematic (dvipdfmx seems ok, but dvips fails)
$ dvips texput.dump.spc.dvi
"This is dvips(k) 2022.1 (TeX Live 2022) Copyright 2022 Radical Eye Software (www.radicaleye.com)
' TeX output 2022.03.10:2237' -> texput.spc.ps
Font number 0 not found
dvips: ! no font selected
but dvitype does not complain about it, so I'm not sure such a DVI file is valid. However, in any circumstances dvi2tty should not cause a segmentation fault.
The resulting "texput.dump.dvi" seems valid (at least for dvitype), but FNTDEF comes before BOP; I think such a DVI format is valid, as dvitype and most of the major DVI drivers accept it. However, there are some issues:
(1) dvi2tty hangs after an error
It waits for user [Return] input, instead of exiting right away.
(2) dvispc fails to print FNTDEF before BOP.
It ignores FNTDEF before BOP as written in "texput.dump.dvi".
(3) dvi2tty crashes while processing dvispc's result
The dvispc's result "texput.dump.spc.dvi" does not contain FNTDEF before BOP or before the appearance of SETCHAR, so it's actually problematic (dvipdfmx seems ok, but dvips fails)
but dvitype does not complain about it, so I'm not sure such a DVI file is valid. However, in any circumstances dvi2tty should not cause a segmentation fault.