Confusing ffStrbufTrim behaviour about fastfetch HOT 6 CLOSED

Can you post the content of the string after each operation? ffStrbufPutTo(&themeStrbuf, stdout); should help. Also how delStrs is declared.

ffStrbufRecalculateLength is not needed, as all strbuf functions always keep the length up to date. I use it only after i let a c function like sscanf write directly in the strbuf buffer. It simply sets the length to the index of the first '\0' char.

from fastfetch.

Update: ffStrbufTrimLeft actually didn't set the null byte at the end. Since i used only strbuf functions which use the length i never encountered an issue with that. But your call of ffStrbufRecalculateLength found the out dated null byte (before the trim) and therefore resized the strbuf to a wrong size. I fixed it just now to avoid bugs with functions that expect a null terminated string.

from fastfetch.

Original string: 		"    <name>Matcha-dark-azul</name>
"
    Matcha-dark-azul

    Matcha-dark-azul
MatcMatcha-dark-

I used recalculate just to see what was happening.
Interestingly, as you can see above, printf("Resulting string: \t\t %s\n", themeStrbuf.chars); is producing a different result than ffStrbufPutTo(&themeStrbuf, stdout);
They're both wrong though. ;)

edit: Ah, so it's fixed then. :)

from fastfetch.

They produce different results as ffStrbufPutTo writes exactly length bytes to the FILE buffer for better performance and printf searches a null byte which was not set.

from fastfetch.

ffStrbufTrimRight actually had a major bug i somehow was lucky to never encounter. Fixed with the latest commit.

from fastfetch.

Indeed it's fixed. GJ.

from fastfetch.