[bug #58962] Latin-1 NO-BREAK SPACE does not behave as documented

[Dave]

Follow-up Comment #6, bug #58962 (project groff):

[comment #5 comment #5:]
> I believe I've cracked this.

Great news!

> $ xxd EXPERIMENTS/dave-58962.roff

I've also attached this file so anyone else who wants to run it doesn't have
to reconstruct it from hex.

> It seems like these cases just weren't ever dealt with in
> the formatter's input parser.

When I run unpatched groff (even as far back as groff 1.19.2), I get the
second line of stderr output, but not the first.  So 0xAD _was_ being handled
somewhere, though seemingly not in token::next().

And while an input 0xA0 didn't match anything according to the
output-comparison operator, it did get interpreted as a fixed-width
nonbreaking space ("\ " to groff) in the output, so it too was being handled,
just not in the way one might have hoped (or, more the the point, not in the
way that was documented).

That is, while the patch as written solves the reported problems, since it
does so only by adding new logic, it would also seem to leave in place some
now-dead code where these two characters were previously handled.  Whether
this is of any practical concern, I leave to you to determine.

(file #53088)

    _______________________________________________________

Additional Item Attachment:

File name: dave-58962.roff                Size:0 KB
    <https://file.savannah.gnu.org/file/dave-58962.roff?file_id=53088>



    _______________________________________________________

Reply to this item at:

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

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