#341 [1.8.1] scroll misbehaves with UTF-8

[aidecoe]

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]

conky config

[aidecoe]

[PATCH] Make scroll UTF-8 aware. Fixes bug #3134941.

[darkfeline]

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

[oss-adv]

I can confirm this as well.

Using Conky 1.9.0.

The patch provided by aidecoe works perfectly.

[oss-adv]

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"},\

[Andreas E]

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():

(original)

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

(new)

#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).

[aidecoe]

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.