2

I'm writing a program in which I use the editline C library to receive user input.

#include <locale.h>
#include <stdio.h>
#include <stdlib.h>

#include <editline/readline.h>
#include <editline/history.h>

int main(int argc, char **argv)
{
    setlocale(LC_ALL, "sr_RS.utf8");

    while (1)
    {
        char *input = readline("prompt> ");

        add_history(input);

        printf("%s\n", input);

        free(input);
    }

    return 0;
}

I'm trying to make the program capable of processing text in cyrillic. I have already set the programs locale to Serbian cyrillic, and it seems to process it fine.

However when using the readline function in the "editline/readline.h" header to process the text, a strange runtime bug happens.

prompt> k
k
prompt> к
к

prompt> k
k

Namely, whenever the line entered contains even a single cyrillic character, the readline function adds an extra line-feed character at the end of the string which isn't usually there.

I inserted a crude check into the while loop to test that this is in fact a problem with the readline function.

while (1)
{
    char *input = readline("prompt> ");

    add_history(input);

    for (int i = 0; input[i] != '\0'; ++i)
    {
        printf("%d\n", (int) input[i]);
    }

    free(input);
}

as expected it gives the following result:

prompt> k
107
prompt> к
-48
-70
10

My question is, where does this extra line-feed character come from, am I misusing the function, and if so, how do I get rid of this problem, or if that's not the case do I simply check for that extra character every line i get and get rid of it. It seems like there should be a cleaner way to get rid of this problem, but I don't know how.

Just for the sake of clarity I'm using Linux Mint on which I've already set up the sr_RS.utf8 locale.

stayhere
  • 41
  • 6
  • For clarity, can you change the negative outputs of the per-character test to unsigned and/or hexadecimal? I can mentally translate signed to unsigned, and hex to UTF8 – but not at the same time `:/` – Jongware Nov 24 '18 at 22:21
  • Cannot reproduce this. What version of libeditline are you using? – n. m. could be an AI Nov 24 '18 at 22:25
  • @usr2564301 sure, then i get this output for к: ffffffd0 ffffffba a – stayhere Nov 24 '18 at 23:00
  • @n.m. my version is 2.0.53 – stayhere Nov 24 '18 at 23:08
  • 1
    Are you sure? I think Mint uses Debian libeditline which is at version 1.x now. Perhaps you can use libedit2, another line editing library somewhat compatible with GNU readline. – n. m. could be an AI Nov 24 '18 at 23:30
  • @n.m. I'd installed the libedit-dev package, and I grepped through my ldconfig -v to find this line: libedit.so.2 -> libedit.so.2.0.53 – stayhere Nov 25 '18 at 11:49
  • I've tried installing libeditline instead of libedit, but then the include fails to work – stayhere Nov 25 '18 at 11:50
  • libeditline0 (link with `-leditline`) seems to implement just two functions, `readline` and `add_history`, both declared in `/usr/include/editline.h`. It doesn't work for me on Ubuntu 18 though the symptoms are different from yours. `libedit` (link with `-ledit`) is more full featured, and is working. – n. m. could be an AI Nov 25 '18 at 16:20
  • @n.m. well since I'm using libedit, i guess I'll try to switch – stayhere Nov 25 '18 at 19:13
  • okay, it seems editline0 can't really process cyrillic, that is while I'm entering the letters, the input just breaks and gives me weird strings of broken symbols instead of cyrillic, at the same time after the string is entered it actually does save all the data without error, but if it's so buggy while the user is actually typing i guess i'll just have to switch back and do that botchy bug fix i was hoping I woudn't have to. – stayhere Nov 25 '18 at 21:53

0 Answers0