Wady scanf

Większość odpowiedzi do tej pory wydaje się skupiać na problemie przepełnienia bufora łańcuchów. W rzeczywistości, specyfikatory formatów, które mogą być używane z funkcjami scanf, obsługują jawne ustawienie szerokości pola , które ogranicza maksymalny rozmiar wejścia i zapobiega przepełnieniu bufora. To sprawia, że popularne oskarżenia o przepełnienie bufora łańcuchów obecne w scanf są praktycznie bezpodstawne. Twierdzenie, że {[0] } jest w jakiś sposób analogiczne do gets pod tym względem jest całkowicie błędne. Jest major różnica jakościowa między scanf a gets: scanf nie jest to jednak możliwe, ponieważ nie jest to możliwe.]}

Można argumentować, że te scanf funkcje są trudne w użyciu, ponieważ szerokość pola musi być osadzona w łańcuchu formatu (nie ma sposobu, aby przekazać go przez zmienny argument, jak to można zrobić w printf). To prawda. {[0] } jest rzeczywiście dość słabo zaprojektowany pod tym względem. Niemniej jednak wszelkie twierdzenia, że {[0] } jest jakoś beznadziejnie złamane w odniesieniu do bezpieczeństwa string-buffer-overflow są całkowicie fałszywe i zwykle wykonane przez leniwych programistów.

Prawdziwy problem z scanf ma zupełnie inną naturę, choć dotyczy również przepełnienia. Gdy funkcja scanf jest używana do konwersji dziesiętnych reprezentacji liczb na wartości typów arytmetycznych, nie zapewnia ochrony przed przepełnieniem arytmetycznym. Jeśli wystąpi przepełnienie, scanf wytworzy nieokreślone zachowanie. Z tego powodu jedynym poprawnym sposobem wykonania konwersji w bibliotece standardowej C są funkcje z rodziny strto....

Tak więc, podsumowując powyższe, problem z scanf polega na tym, że jest to trudne (aczkolwiek możliwe) do prawidłowego i bezpiecznego użycia z buforami łańcuchowymi. I nie można bezpiecznie używać do wprowadzania arytmetycznego. Ten ostatni jest prawdziwym problemem. Ta pierwsza jest tylko niedogodnością.

P. S. powyższe ma dotyczyć całej rodziny scanf funkcji (w tym również fscanf i sscanf). W przypadku scanf oczywistym problemem jest to, że sam pomysł użycia ściśle sformatowanej funkcji do odczytu potencjalnie interaktywnego danych wejściowych jest raczej wątpliwy.

Z komp.lang.C FAQ: dlaczego wszyscy mówią, aby nie używać scanf? Czego powinienem użyć zamiast tego?

scanf ma wiele problemów-zobacz pytania 12.17, 12.18 a , oraz 12.19. Również jego format %s ma ten sam problem co gets() (Zobacz pytanie 12.23)-trudno jest zagwarantować, że bufor odbiorczy nie przepełni się. [przypis]

Bardziej ogólnie, {[0] } jest przeznaczony do stosunkowo structured, formatted input (jego nazwa w rzeczywistości pochodzi od "scan formatted"). Jeśli zwrócisz uwagę, powie Ci, czy się udało, czy nie, ale może powiedzieć tylko w przybliżeniu, gdzie się nie powiodło, a wcale nie jak i dlaczego. Masz bardzo mało możliwości odzyskania błędów.

Interaktywne wejście użytkownika jest jednak najmniej ustrukturyzowanym wejściem. Dobrze zaprojektowany interfejs użytkownika pozwoli na możliwość pisania przez użytkownika niemal wszystkiego-nie tylko liter czy interpunkcja, gdy oczekiwano cyfr, ale także więcej lub mniej znaków niż oczekiwano, lub w ogóle żadnych znaków ( tj., tylko klawisz RETURN), lub przedwczesne EOF, lub cokolwiek innego. Jest prawie niemożliwe, aby z gracją poradzić sobie z tymi wszystkimi potencjalnymi problemami podczas używania scanf; o wiele łatwiej jest odczytać całe wiersze( z fgets lub tym podobne), a następnie zinterpretować je, używając sscanf lub innych technik. (Funkcje takie jak strtol, strtok, i atoi są często przydatne; Zobacz też pytania 12.16 oraz 13.6.) Jeśli używasz dowolnego wariantu scanf, sprawdź wartość zwracaną, aby upewnić się, że znaleziono oczekiwaną liczbę elementów. Ponadto, jeśli używasz %s, pamiętaj, aby chronić przed przepełnieniem bufora.

Zauważ przy okazji, że krytyka scanf niekoniecznie jest oskarżeniem fscanf i sscanf. scanf czyta z stdin, który jest zwykle interaktywną klawiaturą i dlatego jest najmniej ograniczony, co prowadzi do większości problemów. Gdy plik danych ma znany format, z drugiej strony może być właściwe odczytanie go za pomocą fscanf. Jest całkowicie właściwe parsowanie łańcuchów za pomocą sscanf (o ile zwracana wartość jest zaznaczona), ponieważ tak łatwo jest odzyskać kontrolę, ponownie uruchomić skanowanie, odrzucić dane wejściowe, jeśli nie pasują, itd.

Dodatkowe linki:

• dłuższe Wyjaśnienie by Chris Torek
• dłuższe Wyjaśnienie przez yours truly

[[19]}Bibliografia: K & R2 sek. 7.4 str. 159

Tak, masz rację. W rodzinie scanf istnieje poważna wada bezpieczeństwa(scanf,sscanf, fscanf..itd) esp podczas czytania łańcucha, ponieważ nie biorą pod uwagę długości bufora (do którego są odczytywane).

Przykład:

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

Oczywiście bufor buf może pomieścić znak max 3. Ale sscanf spróbuje umieścić "abcdef" w nim powodując przepełnienie bufora.

Bardzo trudno jest zrobić to, co chcesz. Oczywiście, że możesz, ale rzeczy takie jak scanf("%s", buf); są równie niebezpieczne jak gets(buf);, Jak wszyscy mówili.

Jako przykład, co paxdiablo robi w swojej funkcji do czytania, można zrobić za pomocą czegoś takiego:

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

Powyższe spowoduje odczytanie linii, zapisanie pierwszych 10 znaków nie-nowej linii w buf, a następnie odrzucenie wszystkiego do (włącznie) nowej linii. Zatem funkcję paxdiablo można zapisać używając scanf następującego sposób:

#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;
}

Jednym z innych problemów z scanf jest jego zachowanie w przypadku przepełnienia. Na przykład, podczas czytania int:

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

Powyższego nie można bezpiecznie używać w przypadku przepełnienia. Nawet w pierwszym przypadku czytanie ciągu znaków jest o wiele prostsze do zrobienia z fgets, a nie z scanf.

Problemy, które mam z *scanf() rodziną:

• możliwość przepełnienia bufora ze specyfikatorami % s i % [konwersji. Tak, możesz określić maksymalną szerokość pola, ale w przeciwieństwie do printf(), nie możesz uczynić go argumentem w wywołaniu scanf(); musi być zakodowany na twardo w specyfikatorze konwersji.
• potencjał przepełnienia arytmetycznego z %d, % i itd.
• ograniczona zdolność do wykrywania i odrzucania źle uformowanych danych wejściowych. Na przykład, "12w4" nie jest poprawną liczbą całkowitą, ale scanf("%d", &value); będzie pomyślnie przekonwertowano i przypisano 12 do value, pozostawiając "w4" w strumieniu wejściowym, aby zablokować przyszły odczyt. W idealnym przypadku cały łańcuch wejściowy powinien zostać odrzucony, ale scanf() nie daje łatwego mechanizmu, aby to zrobić.

Jeśli wiesz, że Twoje dane wejściowe zawsze będą dobrze uformowane z ciągami o stałej długości i wartościami liczbowymi, które nie flirtują z przepełnieniem, to scanf() jest świetnym narzędziem. Jeśli masz do czynienia z interaktywnym wejściem lub wejściem, które nie jest gwarantowane dobrze uformowany, a następnie użyj czegoś innego.

Wiele odpowiedzi omawia potencjalne problemy z przepełnieniem podczas używania scanf("%s", buf), ale najnowsza Specyfikacja POSIX rozwiązuje ten problem, dostarczając znak m assign-allocation, który może być używany w specyfikacjach formatów dla c, s, i [ formaty. Pozwala to scanf przydzielić tyle pamięci, ile jest to konieczne za pomocą malloc (więc musi zostać uwolniona później za pomocą free).

Przykład jego użycia:

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

// use buf

free(buf);

Zobacz tutaj . Wady takiego podejścia jest to stosunkowo nowy dodatek do specyfikacji POSIX i w ogóle nie jest określony w specyfikacji C, więc na razie pozostaje raczej nieortable.

Jest jeden duży problem z scanf-podobnymi funkcjami-brakiemjakiegokolwiek bezpieczeństwa typu. Oznacza to, że możesz to kodować:

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

Cholera, nawet to jest "w porządku":

scanf("%10s", i);

Jest gorzej niż printf-podobne funkcje, ponieważ scanf oczekuje wskaźnika, więc awarie są bardziej prawdopodobne.

Oczywiście, istnieją pewne Kontrolery określające format, ale te nie są idealne i dobrze, nie są częścią języka lub biblioteki standardowej.

Zaletą scanf jest to, że gdy nauczysz się używać tego narzędzia, jak zawsze powinieneś to robić w C, ma ono niezwykle użyteczne zastosowania. możesz dowiedzieć się, jak używać scanf i przyjaciół, czytając i rozumiejąc podręcznik. Jeśli nie możesz przejść przez ten podręcznik bez poważnych problemów ze zrozumieniem, prawdopodobnie oznacza to, że nie znasz dobrze języka C.

scanf i przyjaciele cierpieli z powodu niefortunnych wyborów projektowych, które utrudniały (i czasami niemożliwe) do poprawnego użycia bez czytania dokumentacji, jak pokazały inne odpowiedzi. Niestety, występuje to w całym C, więc jeśli miałbym odradzać używanie scanf, to prawdopodobnie odradzałbym używanie C.]}

Jedną z największych wad wydaje się być wyłącznie reputacja, którą zdobywa wśród niewtajemniczonych; podobnie jak w przypadku wielu przydatnych funkcji C powinniśmy być dobrze poinformowani, zanim go użyjemy. Kluczem jest uświadomienie sobie, że podobnie jak w przypadku reszty C, to wydaje się zwięzłe i idiomatyczne, ale to może być subtelnie mylące. Jest to wszechobecne w C; początkującym łatwo jest napisać kod, który ich zdaniem ma sens i może nawet zadziałać dla nich na początku, ale nie ma sensu i może zawieść katastrofalnie.