[bug #44018] [PATCH] gtroff hangs in environment::possibly_break_line with -mja

[Ingo Schwarze]

Follow-up Comment #5, bug #44018 (project groff):

Looking at that code, i conclude that *is* already coded very defensively. 
What "int width = 24; int w = wcwidth(get_code(g)); if (w > 1) width *= w;"
does is this:
 * If and only if the C library is sure that the character is double width,
reserve two columns for it.
 * In all other cases, reserve one column for it.  That includes normal
single-width characters, normal zero width-characters (even though you say
they will not usually show up here, but groff allows the user to input *any*
character and the C library does not provide an API to find out whether a
character is combining, the only indication it provides is wcwidth=0, so short
of filtering out wcwidth=0 characters earlier, groff cannot prevent them from
showing up here), and it includes non-printable characters and invalid code
points.

Always reserving a width of at least 24 no matter how broken libc might be is
clearly safe and cannot result in a total width of zero, so i fear we are
looking in the wrong place and this hang is not related to wcwidth, at least
neither to this call of wcwidth nor to the other call in this file, which uses
the same logic.

I only realize now that this was already fixed in
bcdf2f4c7c28328c711c6a7ac2ea17f2ecd5cdd4 (Oct 21 00:29:24 2020 +1100).  But
given the present analysis, isn't the commit message and code comment in that
commit misleading?

    _______________________________________________________

Reply to this item at:

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

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