'strncpy' против 'sprintf'

Ни то, ни другое не должно использоваться вообще.

1. sprintf опасен, устарел и заменен snprintf. Единственный способ безопасного использования старого sprintf со строковыми входными данными — либо измерить их длину перед вызовом sprintf, что некрасиво и чревато ошибками, либо добавить спецификатор точности поля (например, %.8s или %.*s с дополнительным целочисленным аргументом для размера лимит). Это также уродливо и подвержено ошибкам, особенно если задействовано более одного спецификатора %s.

2. strncpy тоже опасно. Это не версия strcpy с ограниченным размером буфера. Это функция для копирования символов в массив фиксированной длины, заполненный нулем (в отличие от заканчивающегося нулем), где источником может быть либо строка C, либо массив символов фиксированной длины, по крайней мере, размер адресата. Его предполагаемое использование было для устаревших таблиц каталогов unix, записей базы данных и т. Д., Которые работали с текстовыми полями фиксированного размера и не хотели тратить впустую ни одного байта на диске или в памяти для нулевого завершения. Его можно неправильно использовать как strcpy с ограниченным размером буфера, но это вредно по двум причинам. Прежде всего, он не завершается нулем, если весь буфер используется для строковых данных (т. е. если длина исходной строки не меньше длины целевого буфера). Вы можете добавить завершение обратно самостоятельно, но это некрасиво и чревато ошибками. И, во-вторых, strncpy всегда дополняет полный буфер назначения нулевыми байтами, когда исходная строка короче выходного буфера. Это просто пустая трата времени.

Так что же использовать вместо этого?

Некоторым нравится функция BSD strlcpy. Семантически он идентичен snprintf(dest, destsize, "%s", source), за исключением того, что возвращаемое значение равно size_t и не накладывает искусственного ограничения INT_MAX на длину строки. Однако в большинстве популярных систем, отличных от BSD, отсутствует strlcpy, и легко допустить опасные ошибки, написав свою собственную, поэтому, если вы хотите использовать ее, вам следует получить безопасную, заведомо работающую версию из надежного источника.

Я предпочитаю просто использовать snprintf для любой нетривиальной конструкции строки и strlen+memcpy для некоторых тривиальных случаев, которые считаются критичными для производительности. Если вы выработаете привычку правильно использовать эту идиому, станет почти невозможно случайно написать код с уязвимостями, связанными со строками.

Различные версии printf/scanf — невероятно медленные функции по следующим причинам:

• Они используют списки переменных аргументов, что усложняет передачу параметров. Делается это с помощью различных непонятных макросов и указателей. Все аргументы должны быть проанализированы во время выполнения, чтобы определить их типы, что добавляет дополнительный служебный код. (Списки VA также довольно избыточная функция языка, а также опасная, поскольку она имеет гораздо более слабую типизацию, чем простая передача параметров.)

• Они должны обрабатывать много сложного форматирования и поддерживать все различные типы. Это также увеличивает нагрузку на функцию. Поскольку все вычисления типов выполняются во время выполнения, компилятор не может оптимизировать части функции, которые никогда не используются. Поэтому, если вы хотите печатать только целые числа с помощью printf(), вы получите поддержку чисел с плавающей запятой, сложную арифметику, обработку строк и т. д. и т. д., связанную с вашей программой, как пустую трату места.

• С другой стороны, такие функции, как strcpy() и особенно memcpy(), сильно оптимизированы компилятором и часто реализуются на встроенном ассемблере для максимальной производительности.

Некоторые измерения, которые я когда-то проводил на 16-битных младших микроконтроллерах barebone, приведены ниже.

Как правило, вы никогда не должны использовать stdio.h в любом виде производственного кода. Его следует рассматривать как библиотеку отладки/тестирования. MISRA-C:2004 запрещает использование stdio.h в производственном коде.

ИЗМЕНИТЬ

Заменил субъективные цифры фактами:

Измерения strcpy и sprintf на целевом Freescale HCS12, компилятор Freescale Codewarrior 5.1. Используя реализацию sprintf C90, C99 будет еще более неэффективным. Все оптимизации включены. Был протестирован следующий код:

  const char str[] = "Hello, world";
  char buf[100];

  strcpy(buf, str);
  sprintf(buf, "%s", str);

Время выполнения, включая перетасовку параметров при включении/выключении стека вызовов:

strcpy   43 instructions
sprintf  467 instructions

Выделенное место для программы/ПЗУ:

strcpy   56 bytes
sprintf  1488 bytes

Выделенное пространство ОЗУ/стека:

strcpy   0 bytes
sprintf  15 bytes

Количество вызовов внутренних функций:

strcpy   0
sprintf  9

Глубина стека вызовов функций:

strcpy   0 (inlined)
sprintf  3 

Я бы не стал использовать sprintf только для копирования строки. Это излишество, и тот, кто прочитает этот код, наверняка остановится и удивится, почему я это сделал, и не упустил ли он (или я) что-то.

Есть один способ использовать sprintf() (или, если вы параноик, snprintf() ), чтобы сделать «безопасную» копию строки, которая усекает вместо того, чтобы переполнять поле или оставлять его без завершения NUL.

То есть использовать символ формата «*» как «строковую точность» следующим образом:

So:

char dest_buff[32];
....
sprintf(dest_buff, "%.*s", sizeof(dest_buff) - 1, unknown_string);

Это помещает содержимое unknown_string в dest_buff, оставляя место для завершающего NUL.