Какие функции в стандартной библиотеке C обычно поощряют плохую практику?

Распространенная ошибка при работе с функцией strtok() состоит в том, что предполагается, что анализируемая строка остается неизменной, тогда как на самом деле она заменяет символ-разделитель на '\0'.

Кроме того, strtok() используется для последующих вызовов до тех пор, пока вся строка не будет размечена. Некоторые реализации библиотек хранят внутренний статус strtok() в глобальной переменной, что может вызвать некоторые неприятные сюрпризы, если strtok() вызывается из нескольких потоков одновременно.

Стандарт безопасного кодирования CERT C многие из этих ловушек, о которых вы спрашивали.

Какие функции стандартной библиотеки C используются ненадлежащим образом/способами, которые могут вызвать/привести к проблемам безопасности/дефектам кода/неэффективности?

Я собираюсь пойти с очевидным:

char *gets(char *s);

С его замечательной особенностью, что использовать его по назначению просто невозможно.

Почти во всех случаях не следует использовать atoi() (это также относится к atof(), atol() и atoll()).

Это связано с тем, что эти функции вообще не обнаруживают ошибки вне допустимого диапазона — стандарт просто говорит "Если значение результата не может быть представлено, поведение не определено".. Таким образом, единственный случай, когда их можно безопасно использовать, — это если вы можете доказать, что ввод определенно будет в пределах диапазона (например, если вы передаете строку длиной 4 или меньше в atoi(), она не может быть вне диапазона).

Вместо этого используйте одну из функций семейства strtol().

Давайте распространим вопрос на интерфейсы в более широком смысле.

errno:

технически даже непонятно что это, переменная, макрос, неявный вызов функции? На практике в современных системах это в основном макрос, который преобразуется в вызов функции, чтобы иметь состояние ошибки, специфичное для потока. Это зло:

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

Предстоящий стандарт дает определение errno немного более прямолинейно, но эти уродства остаются.

Часто встречается файл strtok_r.

Для realloc, если вам нужно использовать старый указатель, не так сложно использовать другую переменную. Если ваша программа завершается с ошибкой выделения памяти, то часто нет необходимости в очистке старого указателя.

Я бы поставил printf и scanf довольно высоко в этом списке. Тот факт, что вы должны точно указать спецификаторы форматирования, делает эти функции сложными в использовании и очень легко ошибиться. Также очень сложно избежать переполнения буфера при считывании данных. Более того, «уязвимость строки формата printf», вероятно, создала бесчисленные дыры в безопасности, когда благонамеренные программисты указывают строки, указанные клиентом, в качестве первого аргумента для printf, только для того, чтобы обнаружить, что стек разбит, а безопасность скомпрометирована много лет спустя.

Любая из функций, управляющих глобальным состоянием, например gmtime() или localtime(). Эти функции просто нельзя безопасно использовать в нескольких потоках.

EDIT: rand() похоже, находится в той же категории. По крайней мере, нет никаких гарантий потокобезопасности, а в моей системе Linux справочная страница предупреждает, что она не поддерживает повторный вход и не является потокобезопасной.

Один из моих самых неприятных моментов — strtok(), потому что он не допускает повторного входа и взламывает строку, которую он обрабатывает, на части, вставляя NUL в конце каждого маркера, который он изолирует. Проблем с этим легион; к сожалению, его часто преподносят как решение проблемы, но так же часто это и есть сама проблема. Не всегда - его можно безопасно использовать. Но только если вы будете осторожны. То же самое относится и к большинству функций, за исключением gets(), которую нельзя использовать безопасно.

Насчет realloc уже есть один ответ, но у меня другое мнение. Много раз я видел, как люди пишут realloc, когда имеют в виду free; malloc - другими словами, когда у них есть буфер, полный мусора, который должен изменить размер перед сохранением новых данных. Это, конечно, приводит к потенциально большому memcpy кешированию хлама, который вот-вот будет перезаписан.

При правильном использовании с растущими данными (таким образом, чтобы избежать наихудшей O(n^2) производительности для увеличения объекта до размера n, т.е. увеличения буфера геометрически, а не линейно, когда вам не хватает места), realloc имеет сомнительное преимущество перед простым выполнением ваших собственных действий. новый цикл malloc, memcpy и free. Единственный способ, с помощью которого realloc может когда-либо избежать этого внутри, - это когда вы работаете с одним объектом в верхней части кучи.

Если вам нравится заполнять нулями новые объекты с помощью calloc, легко забыть, что realloc не заполнит новую часть нулями.

И, наконец, еще одно распространенное использование realloc — выделить больше, чем вам нужно, а затем уменьшить размер выделенного объекта до необходимого размера. Но на самом деле это может быть вредным (дополнительное выделение и memcpy) для реализаций, которые строго разделяют фрагменты по размеру, а в других случаях может увеличить фрагментацию (путем отделения части большого свободного фрагмента для хранения нового небольшого объекта вместо использования существующего). небольшой свободный кусок).

Не уверен, что я бы сказал, что realloc поощряет плохую практику, но я бы остерегся этой функции.

Как насчет семьи malloc в целом? Подавляющее большинство больших долгоживущих программ, которые я видел, повсеместно используют динамическое выделение памяти, как если бы оно было бесплатным. Конечно, разработчики реального времени знают, что это миф, и небрежное использование динамического распределения может привести к катастрофическому увеличению использования памяти и/или фрагментации адресного пространства до точки исчерпания памяти.

В некоторых высокоуровневых языках без указателей машинного уровня динамическое выделение памяти не так уж плохо, потому что реализация может перемещать объекты и дефрагментировать память во время жизни программы, если она может поддерживать актуальность ссылок на эти объекты. Нетрадиционная реализация C тоже могла бы сделать это, но проработка деталей нетривиальна, и это потребовало бы очень значительных затрат на все разыменования указателя и сделало бы указатели довольно большими, поэтому для практических целей это невозможно в C.

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

С другой стороны, я никогда не понимал преимуществ atan(), когда есть atan2(). Разница в том, что atan2() принимает два аргумента и возвращает угол в диапазоне от -π..+π. Кроме того, он позволяет избежать ошибок деления на ноль и ошибок потери точности (деления очень маленького числа на очень большое или наоборот). Напротив, функция atan() возвращает только значение в диапазоне -π/2..+π/2, и вам нужно заранее выполнить деление (я не помню сценария, в котором atan() можно было бы использовать без деления). , за исключением простого создания таблицы арктангенсов). Предоставление 1,0 в качестве делителя для atan2() при задании простого значения не раздвигает границы.

Другой ответ, так как они на самом деле не связаны, rand:

• это неопределенное случайное качество
• это не повторный вход

Некоторые из этих функций изменяют некоторое глобальное состояние. (В Windows) это состояние разделяется на один поток — вы можете получить неожиданный результат. Например, первый вызов rand в каждом потоке даст один и тот же результат, и требуется некоторая осторожность, чтобы сделать его псевдослучайным, но детерминированным (для целей отладки).

basename() и dirname() не являются потокобезопасными.