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

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

Следует ли использовать особую осторожность с этими внешними переменными или они должны рассматриваться не иначе, как любая другая переменная?

0

Решение

extern определяет только связь переменной это не меняет переменную любым другим способом.

Безопасно ли это?

Это так же безопасно / небезопасно, как и любая другая переменная, объявленная переменная extern не имеет никакого отношения.
С помощью strcpy как таковой небезопасен и может вызвать переполнение буфера.
В C ++ лучше использовать вариант std::string

3

Другие решения

Передача любого аргумента strcpy небезопасно и может привести к переполнению буфера. extern не имеет никакого отношения к этому факту. Мудрец использует std::string (или вариант с поддержкой Юникода), и никогда char* или же strcpy или любой из них.

0

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

В общем, хотя, конечно, было бы лучше использовать одну из «безопасных» функций strcpy, которая принимает целевую длину буфера, даже если вы полностью контролируете использование переменной.

0