Gcc-8 -Wstringop-truncation что такое хорошая практика?

Есть очень мало оправданных причин для использования strncpy. Это довольно опасная функция. Если длина исходной строки (без нулевого символа) равна размеру целевого буфера, то strncpy не будет добавлять нулевой символ в конец целевого буфера. Таким образом, буфер назначения не будет завершен нулем.

Мы должны написать такой код в Linux:

lenSrc = strnlen(pSrc, destSize)
if (lenSrc < destSize)
    memcpy(pDest, pSrc, lenSrc + 1);
else {
    /* Handle error... */
}

В вашем случае, если вы хотите усечь источник при копировании, но по-прежнему хотите иметь конечный буфер назначения с нулевым завершением, вы можете написать такой код:

destSize = 32

sizeCp = strnlen(pSrc, destSize - 1);
memcpy(pDest, pSrc, sizeCp);
pDest[sizeCp] = '\0';

Обновлено: О ... Если это не обязательно для завершения NULL, strncpy - правильная функция для использования. И да, вам нужно называть это 32, а не 31. Я думаю, вам нужно проигнорировать это предупреждение, отключив его ... Честно говоря, у меня нет на это хорошего ответа ...

Edit2: Чтобы имитировать функцию strncpy, вы можете написать этот код:

destSize = 32

sizeCp = strnlen(pSrc, destSize - 1);
memcpy(pDest, pSrc, sizeCp + 1);

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

Если вы не хотите или не можете отключить его глобально, вы можете отключить его локально, как указано @doron:

#include <string.h>
char d[32];
void f(const char *s) {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncation"
    strncpy(d, s, 32);
#pragma GCC diagnostic pop
}

Я обнаружил, что лучший способ подавить предупреждение - заключить в скобки выражение как этот патч gRPC:

(strncpy(req->initial_request.name, lb_service_name,
         GRPC_GRPCLB_SERVICE_NAME_MAX_LENGTH));

Проблема с решением для подавления диагностики #pragma заключается в том, что сама #pragma вызывает предупреждение, когда компилятор не распознает ни прагму, ни конкретное предупреждение; также это слишком многословно.

Это новое предупреждение GCC делает strncpy() практически непригодным для использования во многих проектах: проверка кода не принимает код, который выдает предупреждения. Но если strncpy() используется только с достаточно короткими строками, чтобы он мог записать завершающий нулевой байт, то обнуление целевого буфера в начале, а затем простой strcpy() приведет к той же задаче.

Собственно, strncpy() - это одна из функций, которую лучше не помещать в библиотеку C. Конечно, есть законные варианты использования. Но разработчики библиотек забыли также включить в стандарт аналоги strncpy() с фиксированным размером строк. Наиболее важные из таких функций, strnlen() и strndup(), были включены в POSIX.1 только в 2008 году, спустя десятилетия после создания strncpy()! И все еще нет функции, которая копирует сгенерированную strncpy() строку фиксированной длины в предварительно выделенный буфер с правильной семантикой C, то есть всегда записывает 0-завершающий байт. Одной из таких функций может быть:

// Copy string "in" with at most "insz" chars to buffer "out", which
// is "outsz" bytes long. The output is always 0-terminated. Unlike
// strncpy(), strncpy_t() does not zero fill remaining space in the
// output buffer:
char* strncpy_t(char* out, size_t outsz, const char* in, size_t insz){
    assert(outsz > 0);
    while(--outsz > 0 && insz > 0 && *in) { *out++ = *in++; insz--; }
    *out = 0;
    return out;
}

Я рекомендую использовать два входа длины для strncpy_t(), чтобы избежать путаницы: если бы был только один аргумент size, было бы неясно, является ли это размер выходного буфера или максимальная длина входной строки (которая обычно равна единице). меньше).

В нем говорится, что мы можем использовать только символы len - 1, потому что последний должен быть '\ 0', поэтому использование, похоже, очищает предупреждение, которое мы можем скопировать только len - 1 ...

по примерам:

strncpy(this->name, name, 31);

или же

#include <string.h>
char d[32];
void f(const char *s) {
    strncpy(d, s, 31);
}
d[31] = '\0';

TL; DR: обработать случай усечения, и предупреждение исчезнет.

Это предупреждение оказалось для меня действительно полезным, так как обнаружило проблему в моем коде. Рассмотрим этот список:

#include <string.h>
#include <stdio.h>

int main() {
    const char long_string[] = "It is a very long string";
    char short_string[8];
    
    strncpy(short_string, long_string, sizeof(short_string));

    /* This line is extremely important, it handles string truncation */
    short_string[7] = '\0';

    printf("short_string = \"%s\"\n", short_string);

    return 0;
}

demo

Как сказано в комментарии, здесь необходим short_string[7] = '\0';. От человека strncpy:

Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated.

Если мы удалим эту строку, она вызовет UB. Например, у меня программа начинает печатать:

short_string = "It is a It is a very long string"

По сути, GCC хочет, чтобы вы исправили UB. Я добавил такую ​​обработку в свой код, и предупреждение исчезло.

Я нашел это, когда искал почти идеальное решение этой проблемы. Поскольку большинство ответов здесь описывают возможность и способы обработки без подавления предупреждения. В принятом ответе предлагается использовать следующую оболочку, которая приводит к другому набору предупреждений, разочаровывает и нежелательна.

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncation"
    ...
#pragma GCC diagnostic pop

Вместо этого я нашел это рабочее решение, не могу сказать, есть ли какие-то подводные камни, но оно отлично работает.

_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wstringop-truncation\"")
    strncpy(d, s, 32);
_Pragma("GCC diagnostic pop")

Смотрите полную статью здесь.