Package: libnewt0.52
Version: 0.52.10-5+b1
Illustrative command: whiptail --yesno foo 15 77
This may be a bug in fribidi, it all depends on how fribidi_log2vis is
supposed to work. I'm filing it here because it seems to me libnewt0.52
is more likely to be in the wrong.
The signature for that function is:
FriBidiLevel fribidi_log2vis
(
const FriBidiChar *str,
const FriBidiStrIndex len,
FriBidiParType *pbase_dir,
FriBidiChar *visual_str,
FriBidiStrIndex *positions_L_to_V,
FriBidiStrIndex *positions_V_to_L,
FriBidiLevel *embedding_levels
);
str is the input string, and len is the length of this string; str need
not be terminated with a 0 character. In 0.10.9, the visual_str buffer
would have had to be len+1 characters long because fribidi_log2vis would
write a 0 character at visual_str[len]. In 0.19.2 it no longer does
this, which matches the semantics of the input string. But it doesn't
seem to be documented which behavior is intended. I even went to the
upstream CVS, and it seems that this behavior was silently changed in a
rather large code refactoring on 2004-06-07.
At line 295 of newt.c, newt calls fribidi_log2vis passing the length of
the input string (not counting the terminating 0 character) and never
makes sure that the output buffer is actually terminated. In 0.10.9 this
worked fine, but now with 0.19.2 you end up with random garbage after
the button texts.
One simple fix would be to just set out[len] = 0 at line 296 to ensure
proper string termination.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
