Установите первый байт в 0 или используйте memset для «сброса» всего буфера - PullRequest
5 голосов
/ 09 июля 2010

В программировании на С каждый раз, когда я пытаюсь выполнить cat впервые, мне нужно

TCHAR file_name[1024];
// Use memset or set the first byte to 0?
file_name[0] = 0;
_tcscat(file_name, TEMP_DIRECTORY_PATH);
_tcscat(file_name, file);

Я вижу, что большинство программистов используют memset. Но для меня я просто установил первый байт равным 0, чтобы _tcscat знал, с чего начать.

Я не уверен, есть ли какой-либо недостаток / ловушка для этого вместо использования memset?

Спасибо.

Ответы [ 4 ]

4 голосов
/ 09 июля 2010

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

Вы можете принять подход, который Артелиус предложил , и использовать вариант strcpy(), чтобы получить начальную строку в буфер, но я думаю, что симметрия вашего подхода с использованием strcat () `имеет тоже заслуга (хотя я думаю, что достаточно просто установить 1-й символ в 0).

Кроме того, если в буфере могут содержаться «чувствительные» данные (информация о пароле или что-то в этом роде) - это может быть причиной для очистки всего этого. Но если это так, взгляните на http://msdn.microsoft.com/en-us/library/ms972826 по некоторым причинам, почему memset() может быть недостаточно.

3 голосов
/ 09 июля 2010

Вы можете , просто установите первый символ на 0.

Однако еще более простым способом было бы

TCHAR file_name[1024];
_tcsncpy(file_name, TEMP_DIRECTORY_PATH, 1024);
_tcscat(file_name, file);
1 голос
/ 09 июля 2010

Установка всего буфера в NUL-символы является «глубокой защитой». Такая защита скрывает ошибку, допущенную в другом месте исходного кода, возможно, другим программистом. В этом случае ошибкой, за которой следует следить, будет копирование строки, которая помещается в буфер, но не копирование завершающего байта NUL. Уже нулевой буфер будет предоставлять завершающие NUL для этой ошибочной копии строки для «использования». Программисты расходятся во мнении «Глубокая защита», потому что такое кодирование может маскировать ошибки программирования, которые затем могут накапливаться в исходном коде - исправляются только после их появления.

По моему личному мнению, установка буфера для всех символов NUL, таких как «глубокая защита», является огромной тратой. Было бы больше смысла только в NUL последний байт. Тогда ошибки будут видны, но строки в конечном итоге будут прерваны. Как только вы начнете идти по этому пути мышления, «глубокая защита» будет иметь больше смысла, если в буфере будут сделаны два машинных слова длиннее, и эти слова будут обнулены, и, возможно, значение канарейки может сообщить о переполнении буфер и ....

Или вы можете просто не переполнять буферы и написать свою программу так, чтобы она вылетала как можно быстрее, если вы это сделаете. Это то, что я люблю делать.

1 голос
/ 09 июля 2010

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

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