#341 [1.8.1] scroll misbehaves with UTF-8

Code (277)

Just try the following example: ${scroll 10 Zażółcić gęślą jaźń}. The string should be encoded as UTF-8. Conky displays it ok without a scroll, but with it seems to shift string by a single byte instead of by single character. Conky tries to display a half of a character which leads to undesired shift of all text. In result Conky window blinks.


  • aidecoe

    aidecoe - 2010-12-11

    conky config

  • aidecoe

    aidecoe - 2010-12-11
    • summary: scroll misbehaves with UTF-8 --> [1.8.1] scroll misbehaves with UTF-8
  • darkfeline

    darkfeline - 2012-09-29

    I would like to confirm that I am also seeing this behavior, and it is quite annoying.

  • oss-adv

    oss-adv - 2013-09-25

    I can confirm this as well.

    Using Conky 1.9.0.

    The patch provided by aidecoe works perfectly.

  • oss-adv

    oss-adv - 2013-09-26

    Ok, so it seems that after applying the patch, conky has started hanging sometimes when scrolling.

    After extensive experimenting, I found that for certain values of scroll (and step?), some text with a certain length, makes conky hang.

    for example,

    {"full_text":"${scroll 50 5 ${execi 10 cat /tmp/conky}}","color":"\#ffffff"},\

    and a text of 56 characters made conky hang.

    While the following worked fine:

    {"full_text":"${scroll 30 3 ${execi 10 cat /tmp/conky}}","color":"\#ffffff"},\
    Last edit: oss-adv 2013-09-26
  • Andreas E

    Andreas E - 2014-09-26

    OK, I've figured out why the patched scroll.cc tends to hang.
    It's due to an infinite while loop, more exactly this bit:

    //extend length to be shown for wide characters
    j = 0;
    while (j < sd->show + visibcolorchanges + utf8lenfix) {
       charlen = utf8_charlen(*(buf + sd->start + j));
       utf8lenfix += (charlen > 1 ? charlen - 1 : 0);                 
       j += charlen;


    Function utf8_charlen() would (previously) return a -1 once len was outside the [1;4] interval, and this is where the trouble begins:
    j += charlen.
    j is checked in the loop whether its value exceeds the sum (sd->show + visibcolorchanges + utf8lenfix). But charlen may get NEGATIVE and cause j to start counting backwards!! In this case, while loop is never exited - hence the hang.

    I "fixed" it by extending the VALID length from 4 to MAXLEN in function utf8_charlen():


    return (len > 0 && len <= 4) ? len : -1;


    #define MAXLEN 8
    return (len > 0 && len <= MAXLEN) ? len : -1;`

    You probably guessed it: every time the length value exceeded MAXLEN, it returned -1 and messed up the while loop.
    Besides, while debugging quite a lot of those previously "problematic" foreign strings, I've never encountered any length greater than MAXLEN (so far).

    Last edit: Andreas E 2015-08-07
  • aidecoe

    aidecoe - 2015-08-08

    Surprise! ;-) Nothing gets lost in my mailbox.

    Thank you for investigating the issue. You are right, 4 is incorrect, but as far as I read 6 is actually the maximum. In this case the first byte is 1111110x. Anything more than 6 wouldn't make sense. Do you agree with me?

    I have attached the patch (for 1.9.1 branch) with fix as mentiond above.

    Last edit: aidecoe 2015-08-08

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks