Re: groff: grops and grodvi crash on invalid input

[G. Branden Robinson]

At 2020-11-22T13:42:22+1100, John Gardner wrote:
> >
> > In the meantime, John Gardner, who's written his own "ditroff"
> > interpreter in JavaScript, might be able to offer some useful insights
> > on the well-formedness of your sample documents.
> 
> Sorry, I completely missed this.

No worries.  After Brian Carlson's bug submission to Debian 14 years
ago, I think your response looks like a lightning flash.  :-O

> The samples look fine.

Syntactically they might be okay--except arguably for the validity of a
space as a parameter to the "c" command--but there are several other
problems that make the output not render and then render badly once the
first set of problems is fixed.

> Try converting their line-endings from CRLF to LF and see if that
> fixes it.

Now this part is really weird.  I don't know where those came from.
They weren't in Brian's original attachments, and I never convert stuff
_to_ DOS line-ending format without an unusual purpose.  Kind of
baffling.

Anyway, now that the SEGVs are both diagnosed as the one I fixed in June
2019, here's a further look at Brian's input.

There were several problems.

1. He used a positioning command ('V') _before_ the 'p' (new page)
   command.  That's documented in groff_out(5) as against the rules.
2. He vertically positioned to zero.  That sets the text baseline, so
   glyphs would be getting mostly drawn above the top of the page.
3. He declared a groff-compatible ps device resolution of 72000 but
   didn't scale his arguments.  So he said 's10' to set the point size;
   10000 would be more typical.  This combined with the above made it
   look like the page was blank.  Only descenders would be visible, and
   those only at a fraction of a point.
4. Similarly, his horizontal motions between glyphs were far too small.
   'h70' doesn't move you very far.  When I hacked these to 'h7200' the
   glyphs got that authentically unpleasant "xterm -fn variable" effect,
   but they were at least readable and non-overlapping.
5. He didn't handle breaks at all, so the text ran off the right edge of
   the page.
6. As a minor point, he didn't use a page offset; 'H72000' (1 inch) is
   typical.

I'm attaching his version of the grops crasher, my reduced and corrected
version, and a diff between them.

A lot of the above problems could be caught by libdriver and warned
about (though I generally don't like it when _libraries_ emit
diagnostics themselves; instead there should be a communications channel
for errors back to the executable, which reports them).

#1 is a parser state issue and, I think, the most suited for a
diagnostic.  There is never going to be a case where a ditroff document
"meant to do that".

#2 and #5 also seem worthy of consideration, if generalized to "trying
to draw outside the page boundary".

The others are, arguably, cases where we shouldn't get in the way of the
user shooting their toes off.  A printer test page composed in groff
might do all kinds of strange things with microscopic movements.

If there were demand, a ditroff validator could be written which links
with libdriver (it's a static library) and helps people sanity-check
documents in this format.

Just musing.

Any thoughts on the source patch from earlier in the thread which
fattened up libdriver's diagnostic messages?

We're not getting much feedback on 1.23.0.rc1, are we?  :-/

Regards,
Branden

signature.asc
Description: PGP signature