Косяк с функцией замены

Welcome to C and UTF-8 — a world of pain.

Смотри в сторону wchar_t & Co.

В частности strlen → wcslen и т.д.

realloc(*line, llin + (lrep - lpat))

Может

realloc(*line, llin + (lrep - lpat) + 1)

Вообще valgrind для такого есть.

strlen отрабатывает правильно, в нем косяков нет. Он уже давно умеет корректно определять длину строк с со всеми ASCII символами.

Я чувствую, что у меня косяк с memmove, но не вижу, где.

на русских (в кодировке UTF8

Где у меня косяк?

Сколько байт занимает один кириллический символ в UTF8?

Спасибо, ошибка была действительно в этом.

strlen работает не с символами, а с байтами, ему все равно.

strlen работает не с символами, а с байтами, ему все равно.

И что?

Хорошо, в какую последовательность байт превратится 'И'?

В ту же, в которой и приехала в эту рутину.

strlen() реально пофиг. "и" => { 0xD0, 0xB8, 0x00 }

char * attempt = realloc(*line, llin + (lrep - lpat));

Вариант, когда lrep < lpat не рассматривается?

Тогда он зареалочит меньше чем было - результат один и тот же - выделит столько сколько надо.

А вот если «llin + (lrep - lpat)» в итоге выйдет отрицательное, то да, будет весело ))

Чет туплю - вариант событий реальный?

Во-первых, нехорошо делать такие вычитания с unsigned-типами (оно-то работает благодаря дополнительному коду, но всё же). Во-вторых, реаллокнув в меньшую сторону потеряется хвост строки, который возможно надо было ещё перемещать.

Ну, если *line будет указывать на короткую строку (уже в конце цикла) тогда llin будет с малым значением. Может случиться.

Я бы вообще не реалочил, а замалочил бы новый кусок и спокойно б с ним работал, а перед выходом сделал бы фри старого, и вернул указатель на новый.

Во-первых, нехорошо делать такие вычитания с unsigned-типами (оно-то работает благодаря дополнительному коду, но всё же). Во-вторых, реаллокнув в меньшую сторону потеряется хвост строки, который возможно надо было ещё перемещать.

Сейчас поменяю на int32_t.

И поменяю на malloc. Правда после 12тичасовой смены это трудновато сделать с ходу.

Сейчас поменяю на int32_t.

Тогда уж сразу size_t и ptrdiff_t. В случае с отдельным буфером вычитать ничего не придётся.

Стоп, там же по strstr защита стоит, не?

В случае с отдельным буфером вычитать ничего не придётся.

Как не придется? А размер буфера и позици для трех memcpy?

Эм, ну вроде да, упрется в конец строки есичо, должно, по идее.

Просто по идее strstr не пропустит строку, которая не будет содержать как минимум 1 паттерн. По крайней мере я так задумывал.

В общем вот. Может кому пригодится:

char * strrep(char ** line, char * pattern, char * replacer)
{    
    if (!(*line) || (!pattern) || (!replacer))
        return NULL;

    if (strstr(replacer, pattern))
        return NULL;

    int32_t lpat = strlen(pattern);
    int32_t lrep = strlen(replacer);

    char * pcharpat;
    while ((pcharpat = strstr(*line, pattern)) != NULL)
    {
        int32_t ppat = pcharpat - *line;

        int32_t llin = strlen(*line);

        char * attempt = malloc(llin + (lrep - lpat) + 1);
        if (!attempt)
            return NULL;

        memcpy(attempt, *line, ppat);
        memcpy(attempt + ppat, replacer, lrep);
        memcpy(attempt + ppat + lrep, *line + ppat + lpat, llin - ppat - lpat + 1);

        *line = attempt;
    }
    return *line;
}

Ему не нужно итерироваться строго по символу переменной ширины, значит поддержка «широких» символов ему не нужна. А wchar_t тем более, поскольку вне стандарта и на разных платформах он разной ширины.

strlen отрабатывает правильно, в нем косяков нет. Он уже давно умеет корректно определять длину строк с со всеми ASCII символами.

Он всегда умел работать с utf-8 строками. Только возвращал длину строки не в символах, а байтах.

Хорошо, в какую последовательность байт превратится 'И'?

Какое это имеет значение? Для «нуль-терминированного И» strlen вернет 2. О какой проблеме вы говорите?

Сейчас поменяю на int32_t.

Тогда уж сразу size_t

Он беззнаковый, если ТСу нужен знаковый, то есть ssize_t.

Угадай, что я тебе могу посоветовать.

char ** line

Ух, ē-моē! Как все запущено!

А мемори лики кто чистить будет ?

Я затупил, не обращай внимания.

Кстати, по поводу «search&replace» — год назад у нас был маленький конкурс на эту тему:

https://github.com/dim13/lor-contest

конкурс по си

Задача была похожая (убрать подстроку) — можешь почерпать от туда идеи.

[offtop]
А как ты там рамочку в README нарисовал? Я тоже так хочу...
[/offtop]

рамочку могут рисовать лишь те, кто пользуется *BSD!

Это почему?

Загляни — узнаешь. ;) Markdown там.

Тьфу ты! И как я сразу не подумал в содержимое глянуть?

Бля, забыл. Поправлю.