Lorsque j'essaie de compiler du code C qui utilise la gets()fonction avec GCC, j'obtiens cet avertissement:

(.text + 0x34): avertissement: la fonction `gets 'est dangereuse et ne doit pas être utilisée.

Je me souviens que cela a quelque chose à voir avec la protection et la sécurité de la pile, mais je ne sais pas exactement pourquoi.

Comment puis-je supprimer cet avertissement et pourquoi existe-t-il un tel avertissement concernant l'utilisation gets()?

Si gets()c'est si dangereux, alors pourquoi ne pouvons-nous pas le supprimer?

Pour utiliser en getstoute sécurité, vous devez savoir exactement combien de caractères vous lirez, afin de pouvoir créer un tampon suffisamment grand. Vous saurez seulement que si vous savez exactement quelles données vous lirez.

Au lieu d'utiliser gets, vous voulez utiliser fgets, qui a la signature

char* fgets(char *string, int length, FILE * stream);

( fgets, s'il lit une ligne entière, laissera le '\n'dans la chaîne; vous devrez y faire face.)

Il est resté une partie officielle du langage jusqu'à la norme ISO C de 1999, mais il a été officiellement supprimé par la norme de 2011. La plupart des implémentations C le supportent toujours, mais au moins gcc émet un avertissement pour tout code qui l'utilise.

Pourquoi est gets()dangereux

Le premier ver Internet (le Morris Internet Worm ) s'est échappé il y a environ 30 ans (1988-11-02), et il a utilisé gets()un débordement de tampon comme l'une de ses méthodes de propagation d'un système à l'autre. Le problème de base est que la fonction ne sait pas quelle est la taille du tampon, donc elle continue de lire jusqu'à ce qu'elle trouve une nouvelle ligne ou rencontre EOF, et peut déborder les limites du tampon qui lui a été donné.

Vous devez oublier que vous avez déjà entendu dire que cela gets()existait.

La norme C11 ISO / IEC 9899: 2011 a été éliminée en gets()tant que fonction standard, qui est A Good Thing ™ (elle était formellement marquée comme «obsolète» et «obsolète» dans ISO / IEC 9899: 1999 / Cor.3: 2007 - Rectificatif technique 3 pour C99, puis supprimé dans C11). Malheureusement, il restera dans les bibliothèques pendant de nombreuses années (ce qui signifie «décennies») pour des raisons de rétrocompatibilité. Si cela ne tenait qu'à moi, la mise en œuvre de gets()deviendrait:

char *gets(char *buffer)
{
    assert(buffer != 0);
    abort();
    return 0;
}

Étant donné que votre code se bloquera de toute façon, tôt ou tard, il est préférable de régler le problème plus tôt que tard. Je serais prêt à ajouter un message d'erreur:

fputs("obsolete and dangerous function gets() called\n", stderr);

Les versions modernes du système de compilation Linux génèrent des avertissements si vous établissez un lien gets()- et également pour certaines autres fonctions qui ont également des problèmes de sécurité ( mktemp(),…).

Alternatives à gets()

fgets ()

Comme tout le monde l' a déjà dit, l'alternative canonique gets()est en fgets()spécifiant stdinque le flux de fichiers.

char buffer[BUFSIZ];

while (fgets(buffer, sizeof(buffer), stdin) != 0)
{
    ...process line of data...
}

Ce que personne d'autre n'a encore mentionné, c'est qu'il gets()n'inclut pas la nouvelle ligne mais le fgets()fait. Ainsi, vous devrez peut-être utiliser un wrapper fgets()qui supprime la nouvelle ligne:

char *fgets_wrapper(char *buffer, size_t buflen, FILE *fp)
{
    if (fgets(buffer, buflen, fp) != 0)
    {
        size_t len = strlen(buffer);
        if (len > 0 && buffer[len-1] == '\n')
            buffer[len-1] = '\0';
        return buffer;
    }
    return 0;
}

Ou mieux:

char *fgets_wrapper(char *buffer, size_t buflen, FILE *fp)
{
    if (fgets(buffer, buflen, fp) != 0)
    {
        buffer[strcspn(buffer, "\n")] = '\0';
        return buffer;
    }
    return 0;
}

De plus, comme le souligne caf dans un commentaire et paxdiablo le montre dans sa réponse, fgets()vous pourriez avoir des données sur une ligne. Mon code wrapper laisse ces données à lire la prochaine fois; vous pouvez facilement le modifier pour engloutir le reste de la ligne de données si vous préférez:

        if (len > 0 && buffer[len-1] == '\n')
            buffer[len-1] = '\0';
        else
        {
             int ch;
             while ((ch = getc(fp)) != EOF && ch != '\n')
                 ;
        }

Le problème résiduel est de savoir comment signaler les trois états de résultat différents - EOF ou erreur, ligne lue et non tronquée, et ligne partielle lue mais les données ont été tronquées.

Ce problème ne se pose pas gets()car il ne sait pas où se termine votre tampon et piétine joyeusement au-delà de la fin, faisant des ravages sur votre disposition de mémoire magnifiquement entretenue, gâchant souvent la pile de retour (un débordement de pile ) si le tampon est alloué sur la pile, ou le piétinement sur les informations de contrôle si le tampon est alloué dynamiquement, ou la copie de données sur d'autres précieuses variables globales (ou module) si le tampon est alloué statiquement. Rien de tout cela n'est une bonne idée - ils incarnent l'expression «comportement indéfini».

Il existe également le TR 24731-1 (rapport technique du comité de normalisation C) qui offre des alternatives plus sûres à une variété de fonctions, notamment gets():

§6.5.4.1 La gets_sfonction

Synopsis

#define __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
char *gets_s(char *s, rsize_t n);

Contraintes d'exécution

sne doit pas être un pointeur nul. nne doit pas être égal à zéro ni supérieur à RSIZE_MAX. Un caractère de nouvelle ligne, une fin de fichier ou une erreur de lecture doit se produire dans la lecture des n-1caractères de stdin. ²⁵⁾

3 S'il y a une violation de contrainte d'exécution, s[0]est défini sur le caractère nul et les caractères sont lus et ignorés stdinjusqu'à ce qu'un caractère de nouvelle ligne soit lu, ou à la fin du fichier ou qu'une erreur de lecture se produise.

La description

4 La gets_sfonction lit au plus un de moins que le nombre de caractères spécifié par n dans le flux pointé par stdin, dans le tableau pointé par s. Aucun caractère supplémentaire n'est lu après un caractère de nouvelle ligne (qui est supprimé) ou après la fin du fichier. Le caractère de nouvelle ligne supprimé ne compte pas dans le nombre de caractères lus. Un caractère nul est écrit immédiatement après le dernier caractère lu dans le tableau.

5 Si la fin du fichier est rencontrée et qu'aucun caractère n'a été lu dans le tableau, ou si une erreur de lecture se produit pendant l'opération, le s[0]paramètre est défini sur le caractère nul et les autres éléments de sprennent des valeurs non spécifiées.

Pratique recommandée

6 La fgetsfonction permet aux programmes correctement écrits de traiter en toute sécurité les lignes d'entrée trop longtemps pour être stockées dans le tableau de résultats. En général, cela nécessite que les appelants soient fgetsattentifs à la présence ou à l'absence d'un caractère de nouvelle ligne dans le tableau de résultats. Envisagez d'utiliser fgets(avec tout traitement nécessaire basé sur des caractères de nouvelle ligne) au lieu de gets_s.

²⁵⁾ La gets_sfonction, contrairement à gets, en fait une violation de contrainte d'exécution pour qu'une ligne d'entrée déborde le tampon pour le stocker. Contrairement à fgets, gets_smaintient une relation un à un entre les lignes d'entrée et les appels réussis vers gets_s. Les programmes qui utilisent getss'attendent à une telle relation.

Les compilateurs Microsoft Visual Studio implémentent une approximation de la norme TR 24731-1, mais il existe des différences entre les signatures implémentées par Microsoft et celles du TR.

La norme C11, ISO / IEC 9899-2011, inclut TR24731 dans l'annexe K en tant que partie facultative de la bibliothèque. Malheureusement, il est rarement implémenté sur des systèmes de type Unix.

getline() - POSIX

POSIX 2008 fournit également une alternative sûre aux gets()appels getline(). Il alloue de l'espace de manière dynamique à la ligne, vous avez donc besoin de la libérer. Il supprime donc la limitation de la longueur de ligne. Il renvoie également la longueur des données lues, ou -1(et non EOF!), Ce qui signifie que les octets nuls dans l'entrée peuvent être traités de manière fiable. Il existe également une variante «choisissez votre propre délimiteur à caractère unique» appelée getdelim(); cela peut être utile si vous traitez la sortie d' find -print0où les extrémités des noms de fichiers sont marquées avec un caractère ASCII NUL '\0', par exemple.

Parce getsqu'il ne fait aucune vérification en récupérant des octets de stdin et en les plaçant quelque part. Un exemple simple:

char array1[] = "12345";
char array2[] = "67890";

gets(array1);

Maintenant, tout d'abord, vous êtes autorisé à entrer le nombre de caractères que vous voulez, getscela ne vous importera pas. Deuxièmement, les octets sur la taille du tableau dans lequel vous les placez (dans ce cas array1) écraseront tout ce qu'ils trouveront en mémoire car getsils les écriront. Dans l'exemple précédent, cela signifie que si vous saisissez "abcdefghijklmnopqrts"peut-être, de manière imprévisible, il sera également écrasé array2ou autre.

La fonction n'est pas sûre car elle suppose une entrée cohérente. NE L'UTILISEZ JAMAIS!

Vous ne devez pas l'utiliser getscar il n'a aucun moyen d'arrêter un débordement de tampon. Si l'utilisateur tape plus de données que ne peut en contenir votre tampon, vous vous retrouverez très probablement avec une corruption ou pire.

En fait, l'ISO a en fait pris la décision de retirer gets de la norme C (à partir de C11, bien qu'elle soit déconseillée en C99) qui, étant donné le taux élevé de compatibilité ascendante, devrait être une indication de la gravité de cette fonction.

La bonne chose à faire est d'utiliser la fgetsfonction avec le stdindescripteur de fichier car vous pouvez limiter les caractères lus par l'utilisateur.

Mais cela a aussi ses problèmes tels que:

• les caractères supplémentaires saisis par l'utilisateur seront récupérés la prochaine fois.
• il n'y a pas de notification rapide que l'utilisateur a entré trop de données.

À cette fin, presque tous les codeurs C à un moment donné de leur carrière écriront également un wrapper plus utile fgets. Voici la mienne:

#include <stdio.h>
#include <string.h>

#define OK       0
#define NO_INPUT 1
#define TOO_LONG 2
static int getLine (char *prmpt, char *buff, size_t sz) {
    int ch, extra;

    // Get line with buffer overrun protection.
    if (prmpt != NULL) {
        printf ("%s", prmpt);
        fflush (stdout);
    }
    if (fgets (buff, sz, stdin) == NULL)
        return NO_INPUT;

    // If it was too long, there'll be no newline. In that case, we flush
    // to end of line so that excess doesn't affect the next call.
    if (buff[strlen(buff)-1] != '\n') {
        extra = 0;
        while (((ch = getchar()) != '\n') && (ch != EOF))
            extra = 1;
        return (extra == 1) ? TOO_LONG : OK;
    }

    // Otherwise remove newline and give string back to caller.
    buff[strlen(buff)-1] = '\0';
    return OK;
}

avec du code de test:

// Test program for getLine().

int main (void) {
    int rc;
    char buff[10];

    rc = getLine ("Enter string> ", buff, sizeof(buff));
    if (rc == NO_INPUT) {
        printf ("No input\n");
        return 1;
    }

    if (rc == TOO_LONG) {
        printf ("Input too long\n");
        return 1;
    }

    printf ("OK [%s]\n", buff);

    return 0;
}

Il offre les mêmes protections que fgetsdans la mesure où il empêche les débordements de tampon mais il informe également l'appelant de ce qui s'est passé et efface les caractères en excès afin qu'ils n'affectent pas votre prochaine opération d'entrée.

N'hésitez pas à l'utiliser comme vous le souhaitez, je le libère sous la licence "faites ce que vous voulez bien" :-)

fgets .

Pour lire à partir du stdin:

char string[512];

fgets(string, sizeof(string), stdin); /* no buffer overflows here, you're safe! */

Vous ne pouvez pas supprimer les fonctions de l'API sans casser l'API. Si vous le faites, de nombreuses applications ne seront plus compilées ou exécutées du tout.

C'est la raison pour laquelle une référence donne:

La lecture d'une ligne qui déborde du tableau pointé par s entraîne un comportement indéfini. L'utilisation de fgets () est recommandée.

J'ai lu récemment, dans un article USENET àcomp.lang.c , qui gets()est en train d'être supprimé de la norme. WOOHOO

Vous serez heureux de savoir que le comité vient de voter (à l'unanimité, en fin de compte) pour supprimer gets () du projet également.

Dans C11 (ISO / IEC 9899: 201x), gets()a été supprimé. (Il est déconseillé dans ISO / IEC 9899: 1999 / Cor.3: 2007 (E))

De plus fgets(), C11 présente une nouvelle alternative sûre gets_s():

C11 K.3.5.4.1 La gets_sfonction

#define __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
char *gets_s(char *s, rsize_t n);

Cependant, dans la section Pratique recommandée , fgets()est toujours préférable.

La fgetsfonction permet aux programmes correctement écrits de traiter en toute sécurité les lignes d'entrée trop longtemps pour être stockées dans le tableau de résultats. En général, cela nécessite que les appelants soient fgetsattentifs à la présence ou à l'absence d'un caractère de nouvelle ligne dans le tableau de résultats. Envisagez d'utiliser fgets(avec tout traitement nécessaire basé sur des caractères de nouvelle ligne) au lieu de gets_s.

gets()est dangereux car il est possible pour l'utilisateur de planter le programme en tapant trop dans l'invite. Il ne peut pas détecter la fin de la mémoire disponible, donc si vous allouez une quantité de mémoire trop petite à cet effet, cela peut provoquer une erreur de segmentation et un crash. Parfois, il semble très improbable qu'un utilisateur tape 1000 lettres dans une invite destinée au nom d'une personne, mais en tant que programmeurs, nous devons rendre nos programmes à l'épreuve des balles. (cela peut également représenter un risque pour la sécurité si un utilisateur peut planter un programme système en envoyant trop de données).

fgets() vous permet de spécifier le nombre de caractères à retirer du tampon d'entrée standard, afin qu'ils ne dépassent pas la variable.

Je voudrais adresser une invitation sérieuse à tous les responsables de bibliothèques C qui sont toujours inclus getsdans leurs bibliothèques "juste au cas où quelqu'un en dépendrait encore": veuillez remplacer votre implémentation par l'équivalent de

char *gets(char *str)
{
    strcpy(str, "Never use gets!");
    return str;
}

Cela vous aidera à vous assurer que personne n'en dépend encore. Je vous remercie.

La fonction C gets est dangereuse et a été une erreur très coûteuse. Tony Hoare le souligne pour une mention spécifique dans son discours "Null References: The Billion Dollar Mistake":

http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

Toute l'heure mérite d'être regardée, mais pour ses commentaires, la vue à partir de 30 minutes avec le détail obtient une critique d'environ 39 minutes.

J'espère que cela vous mettra en appétit pour toute la discussion, ce qui attire l'attention sur la façon dont nous avons besoin de preuves de correction plus formelles dans les langues et sur la façon dont les concepteurs de langues devraient être blâmés pour les erreurs dans leurs langues, pas sur le programmeur. Cela semble avoir été la raison douteuse pour les concepteurs de mauvais langages de rejeter la faute sur les programmeurs sous le couvert de la «liberté du programmeur».