Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 138445 - off-by-one in slang SLsmg_draw_hline()
off-by-one in slang SLsmg_draw_hline()
Product: Fedora
Classification: Fedora
Component: slang (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
Depends On:
  Show dependency treegraph
Reported: 2004-11-09 06:58 EST by Egmont Koblinger
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.4.9 Rel. 19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 10:43:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Egmont Koblinger 2004-11-09 06:58:16 EST
In the slang-1.4.9-6 package the slang-utf8-acs.patch introduces an
off-by-one error in SLsmg_draw_hline(), actually, it draws a line
which is one character longer than the requested length.

Looking at the patch it's trivial, the mainstream slang code is
changed by this patch to:

SLsmg_draw_object(This_Row, This_Col, ch);
while (n-- > 0)
    SLsmg_draw_object(This_Row, This_Col, ch);

which is supposed to print n characters, but obviously prints n+1.
Fix is trivial: remove the function call above the 'while'.
(Note that mainstream slang is not buggy.)

This causes a misbehavior if you compile a mainstream unpached 'mc'
using the slang library. The horizontal line that separates the
file list and the mini status bar is too long on its right end.

Fedora's mc-4.6.1-0.8's mc-CVS-utf8.patch workarounds this bug of
slang in src/screen.c:
-    hline (ACS_HLINE, panel->widget.cols - 2);
+    hline (ACS_HLINE, panel->widget.cols - 3);
which is brain-damaged and should be dropped once slang is fixed.
Comment 1 Leonard den Ottolander 2004-11-11 09:46:49 EST
This hunk has already been dropped from the utf8 patch. It actually
caused drawing errors for me on FC1. So this is a regression in FC3 then?
Comment 2 Egmont Koblinger 2004-11-11 10:00:50 EST
I don't know if it was buggy or not in previous FC versions,
but in FC3 this hunk is definitely there and it behaves buggy.

Anyway, what's the origin of these utf8 patches, do you know?
I'm just curious...
Comment 3 Leonard den Ottolander 2004-11-11 10:10:24 EST
The hunk was removed from that patch for 4.6.1-0.9 which is in RawHide.

Regarding the origin of the mc UTF-8 patches please contact me per email.
Comment 4 Jindrich Novy 2004-11-11 11:33:17 EST
Egmont, the hunk is no more present in the latest mc-4.6.1-0.9, so I
agree with Leonard. Since our servers are rather overloaded at the
time, you can dowload the latest mc release from:


I'll appreciate any suggestions.

Leonard, it was unfortunately too late to include this mc to FC3.
Comment 5 Egmont Koblinger 2004-11-11 11:55:06 EST
I only checked FC3 when reporting the bug.
The mc-4.6.1-0.9 is really okay in this respect.
If you say slang is also fixed since FC3, then it means this bug can
be closed as fixed, ain't it? :-)
Comment 6 Leonard den Ottolander 2004-11-11 12:51:15 EST
Comment 5: slang is not necessarily fixed already.

Comment 4: Because of the quoting issues we will need an update for
FC3 anyway. Then this should automatically be fixed.

Adrian, sorry for the OT in this bug report. Regarding the actual
issue with slang:

Comment 1: Will replacing "while (n-- > 0)" with "while (--n > 0)" or
"while (n-- > 1)" fix this issue?
Comment 7 Egmont Koblinger 2004-11-11 13:00:47 EST

If you write "while (--n > 0)" or "while (n-- > 1)" then it'll be
okay for the n>1 case, however, if one calls SLsmg_draw_hline()
with n==0, which is supposed to do nothing, then it'll still draw
one character. Hence I think it's safer to stick to my original

Also please note that in case a fixed slang is released as an FC3
update without a fixed mc, or a fixed mc is released without a fixed
slang, then the horizontal line between the filelist and the mini
status bar will be either too short or too long. So be careful with
Comment 8 Egmont Koblinger 2004-11-11 13:12:34 EST
... will be okay for the _ n>=1 _ case I mean...
Comment 9 Eido Inoue 2004-11-11 14:54:27 EST
comment 2: i believe the subsequent utf8 patches after the initial
debian one were hacked in-house to address line drawing badness,
especially with anaconda text environment (using dietlibc) + newt + CJK.

comment 6,7: while (--n > 0) is no good because n is unsigned int,
which will cause n to wrap around to UINT_MAX if n == 0. (not sure if
compute_clip() will change cmax and cmin to be equal to each other,
causing this condition, unless you resize the window to an absurd
size. but still...)

irc, the double draw (one character even if n == 0) was originally
done to hack around some glitchiness with CJK. whether or not the CJK
issue re-appears will need to be re-tested.

will push the modified version to fedora-testing
Comment 10 Eido Inoue 2004-11-11 15:37:37 EST
potential fix (in need of lots of i18n testing) in -9... pushed to
testing repository
Comment 11 Eido Inoue 2004-11-12 15:37:10 EST
*** Bug 127700 has been marked as a duplicate of this bug. ***
Comment 12 Leonard den Ottolander 2005-01-09 16:11:09 EST
Issue also exists on RHEL 3 (slang-1.4.5-18).
Comment 13 Rahul Sundaram 2005-09-05 03:38:27 EDT
whats the status on this?
Comment 14 Petr Raszyk 2005-09-05 10:42:06 EDT
Fixed in devel CURRENT RELEASE (slang 1.4.9 Rel.19).
Fixed in FEDORA CORE 4 CURRENT RELEASE (slang 1.4.9. Rel. 19.fc4).
It works in FEDORA CORE 3 CURRENT RELEASE (slang 1.4.9 Rel.13).

We have tried to compile midnight-commander (CURRENT RELEASE in 
devel, FEDORA CORE 4 and FEDORA CORE 3) always with 
slang 1.4.9 Rel.19 (CURRENT RELEASE).

The issue above could not be reproduced.

Note You need to log in before you can comment on or make changes to this bug.