Недостатки сканирования

Очень трудно заставить scanf делать то, что вы хотите. Конечно, можно, но такие вещи, как scanf("%s", buf);, так же опасны, как и gets(buf);, как все говорят.

Например, то, что делает paxdiablo в своей функции чтения, можно сделать с помощью чего-то вроде:

scanf("%10[^\n]%*[^\n]", buf));
getchar();

Вышеупомянутое будет читать строку, сохранять первые 10 символов, отличных от новой строки, в buf, а затем отбрасывать все до (и включая) новой строки. Итак, функция paxdiablo может быть записана с использованием scanf следующим образом:

#include <stdio.h>

enum read_status {
    OK,
    NO_INPUT,
    TOO_LONG
};

static int get_line(const char *prompt, char *buf, size_t sz)
{
    char fmt[40];
    int i;
    int nscanned;

    printf("%s", prompt);
    fflush(stdout);

    sprintf(fmt, "%%%zu[^\n]%%*[^\n]%%n", sz-1);
    /* read at most sz-1 characters on, discarding the rest */
    i = scanf(fmt, buf, &nscanned);
    if (i > 0) {
        getchar();
        if (nscanned >= sz) {
            return TOO_LONG;
        } else {
            return OK;
        }
    } else {
        return NO_INPUT;
    }
}

int main(void)
{
    char buf[10+1];
    int rc;

    while ((rc = get_line("Enter string> ", buf, sizeof buf)) != NO_INPUT) {
        if (rc == TOO_LONG) {
            printf("Input too long: ");
        }
        printf("->%s<-\n", buf);
    }
    return 0;
}

Еще одна проблема с scanf — его поведение в случае переполнения. Например, при чтении int:

int i;
scanf("%d", &i);

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

Да, ты прав. Существует серьезный недостаток безопасности в scanf family(scanf,sscanf, fscanf..etc) esp при чтении строки, потому что они не учитывают длину буфера (в который они считываются).

Пример:

char buf[3];
sscanf("abcdef","%s",buf);

ясно, что буфер buf может содержать MAX 3 символов. Но sscanf попытается поместить в него "abcdef", что вызовет переполнение буфера.

Проблемы, которые у меня есть с семьей *scanf():

• Возможность переполнения буфера со спецификаторами преобразования %s и %[. Да, вы можете указать максимальную ширину поля, но, в отличие от printf(), вы не можете сделать его аргументом в вызове scanf(); это должно быть жестко закодировано в спецификаторе преобразования.
• Возможно арифметическое переполнение с помощью %d, %i и т. д.
• Ограниченная способность обнаруживать и отклонять плохо сформированные входные данные. Например, «12w4» не является допустимым целым числом, но scanf("%d", &value); успешно преобразует и присвоит 12 value, оставив «w4» застрявшим во входном потоке, чтобы испортить будущее чтение. В идеале вся входная строка должна быть отклонена, но scanf() не дает вам простого механизма для этого.

Если вы знаете, что ваш ввод всегда будет правильно сформирован со строками фиксированной длины и числовыми значениями, которые не заигрывают с переполнением, то scanf() — отличный инструмент. Если вы имеете дело с интерактивным вводом или вводом, который не гарантируется правильно сформированным, используйте что-то другое.

Во многих ответах здесь обсуждаются потенциальные проблемы переполнения при использовании scanf("%s", buf), но последняя спецификация POSIX более или менее решает эту проблему, предоставляя символ назначения-распределения m, который можно использовать в спецификаторах формата для форматов c, s и [. Это позволит scanf выделить столько памяти, сколько необходимо с помощью malloc (поэтому ее необходимо освободить позже с помощью free).

Пример его использования:

char *buf;
scanf("%ms", &buf); // with 'm', scanf expects a pointer to pointer to char.

// use buf

free(buf);

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

У scanf-подобных функций есть одна большая проблема — отсутствие безопасности типов any. То есть вы можете закодировать это:

int i;
scanf("%10s", &i);

Черт, даже это "хорошо":

scanf("%10s", i);

Это хуже, чем printf-подобные функции, потому что scanf ожидает указатель, поэтому сбои более вероятны.

Конечно, есть некоторые средства проверки спецификаторов формата, но они не идеальны и не являются частью языка или стандартной библиотеки.

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

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

Одним из самых больших недостатков, по-видимому, является репутация, которую он заработал среди непосвященных; как и со многими полезными функциями C, мы должны быть хорошо информированы, прежде чем использовать его. Ключ в том, чтобы понять, что, как и в остальной части C, он кажется кратким и идиоматичным, но это может слегка ввести в заблуждение. Это распространено в C; новичкам легко написать код, который, по их мнению, имеет смысл и может даже работать на них изначально, но не имеет смысла и может привести к катастрофическим сбоям.

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

Каким был бы ответ на этот вопрос, если бы не упоминание о его небезопасности и риске переполнения буфера? Как мы уже говорили, C не является безопасным языком и позволит нам срезать углы, возможно, применить оптимизацию за счет корректности или, что более вероятно, потому что мы ленивые программисты. Таким образом, когда мы знаем, что система никогда не получит строку больше фиксированного числа байтов, нам предоставляется возможность объявить массив такого размера и отказаться от проверки границ. Я действительно не вижу в этом падения; это вариант. Опять же, настоятельно рекомендуется прочитать руководство, которое откроет нам эту возможность.

Не только ленивые программисты страдают от scanf. Нередко можно увидеть, как люди пытаются прочитать значения float или double, используя, например, %d. Обычно они ошибаются, полагая, что реализация будет выполнять какое-то преобразование за кулисами, что имеет смысл, поскольку подобные преобразования происходят во всем остальном языке, но здесь это не так. Как я уже говорил ранее, scanf и друзья (и, конечно же, остальные члены C) обманчивы; они кажутся краткими и идиоматическими, но это не так.

Неопытные программисты не обязаны учитывать успех операции. Предположим, пользователь вводит что-то совершенно нечисловое, когда мы сказали scanf прочитать и преобразовать последовательность десятичных цифр, используя %d. Единственный способ перехватить такие ошибочные данные — это проверить возвращаемое значение, а как часто мы утруждаем себя проверкой возвращаемого значения?

Подобно fgets, когда scanf и друзья не могут прочитать то, что им велят прочитать, поток останется в необычном состоянии; – В случае fgets, если не хватает места для сохранения полной строки, то оставшаяся часть строки, оставшаяся непрочитанной, может быть ошибочно воспринята как новая строка, когда это не так. - В случае scanf и друзей, преобразование завершилось неудачно, как описано выше, ошибочные данные остаются непрочитанными в потоке и могут быть ошибочно обработаны, как если бы они были частью другого поля.

Использовать scanf и друзей не проще, чем fgets. Если мы проверим успех, ища '\n', когда мы используем fgets, или проверим возвращаемое значение, когда мы используем scanf и других, и обнаружим, что мы прочитали неполную строку, используя fgets, или не смогли прочитать поле, используя scanf , то мы сталкиваемся с той же реальностью: мы, вероятно, отбрасываем ввод (обычно до следующей новой строки включительно)! Юууууук!

К сожалению, scanf одновременно усложняет (неинтуитивно) и упрощает (наименьшее количество нажатий клавиш) отбрасывание ввода таким образом. Столкнувшись с этой реальностью отказа от пользовательского ввода, некоторые пытались использовать scanf("%*[^\n]%*c");, не понимая, что делегат %*[^\n] потерпит неудачу, если не встретит ничего, кроме новой строки, и, следовательно, новая строка все равно останется в потоке.

Небольшая адаптация путем разделения двух делегатов формата, и мы видим здесь некоторый успех: scanf("%*[^\n]"); getchar();. Попробуйте сделать это с таким количеством нажатий клавиш, используя какой-нибудь другой инструмент;)