bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #44018] [PATCH] gtroff hangs in environment::possibly_break_line wi


From: Ingo Schwarze
Subject: [bug #44018] [PATCH] gtroff hangs in environment::possibly_break_line with -mja
Date: Fri, 24 Sep 2021 08:03:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:92.0) Gecko/20100101 Firefox/92.0

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

Re comment #2:

I sense a possible contradiction in this comment: "returning zero" is not the
same as "negative character widths".

Regarding the first sentence, for wcwidth(3), a zero return value means the
character takes up no horizontal space.  That is the expected return value for
*many* characters for a variety of reasons, for example zero-width spaces and
combining accents.  So i expect it would be possible to construct a line of
total length zero by including several character, but all of them of wcwidth
zero.

Regarding the second sentence, for wcwidth(3), a return value of -1 means that
the character is not printable.  In that case, adding that -1 to the line
length would indeed be a bug.  Possible courses of actions are erroring out,
inserting a replacement character, or just skipping the character, whatever
seems most helpful in the case at hand.

Since wcwidth(3) is usually provided by the operating system in the C library,
portable code must make sure that it can deal with any return value for any
character.  Subtle differences exist between the wcwidth(3) return values of
some characters between Linux and BSD and even between different BSD systems. 
In some commercial systems, most notably even the latest releases of Oracle
Solaris, wcwidth(3) is quite badly broken and returns clearly wrong values for
many characters, including -1 or 0 for many characters that should be width +1
or +2.  On such systems, portable software cannot reasonably avoid minor
output glitches, but it can implement careful and correct handling of return
values to reduce the risk of letting wrong return values go unnoticed, and
even more so to avoid hangs and crashes.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]