2009-07-31 17 views
6

Ich verwende die Funktion gets() in meinem C-Code. Mein Code funktioniert gut, aber ich bin immer eine WarnmeldungDeaktivieren Sie Warnmeldungen in GCC über Header-Dateien?

(.text+0xe6): warning: the `gets' function is dangerous and should not be used. 

Ich möchte diese Warnmeldung nicht aufzutauchen. Gibt es irgendeinen Weg?

Ich wundere mich, dass es solche Möglichkeiten geben könnte, indem Sie eine Header-Datei zum Deaktivieren einiger Warnungen erstellen. Oder gibt es eine Option beim Kompilieren, die meinem Zweck dienen kann? Oder gibt es eine bestimmte Art der Verwendung von gets() für diese Warnung nicht zu Pop-up?

Antwort

27

Die offensichtliche Antwort ist, aus dem zu lernen, was der Compiler Ihnen zu sagen versucht - Sie sollten niemals gets() verwenden, da es völlig unsicher ist. Verwenden Sie stattdessen fgets(), wodurch Sie mögliche Pufferüberläufe verhindern können.

#define BUFFER_SIZE 100 
char buff[BUFFER_SIZE]; 
gets(buff); // unsafe! 
fgets(buff, sizeof(buff), stdin); // safe 
+0

Dank Neil ... fgets funktioniert gut. Danke vielmals. –

+3

Im wirklichen Leben werden Sie wahrscheinlich "sizeof buff" verwenden wollen, anstatt die Puffergröße zu duplizieren. –

+3

Im wirklichen Leben werden Sie den Puffer über eine Konstante wie BUFFSIZE Größe und verwenden Sie auch das im Aufruf fgets(). –

10

würde ich die Warnung beachten und gets ersetzen. Das ist deutlich genug für mich:

BUGS

Niemals gets(). Da es unmöglich ist, ohne zu wissen, die Daten in Fortschritt, wie viele Zeichen bekommt() gelesen wird, und weil gets() weiterhin Zeichen über das Ende des Puffers speichern wird, ist es äußerst gefährlich zu verwenden. Es wurde verwendet, um Computersicherheit zu brechen. Verwenden Sie stattdessen fgets().

8

Verwendung fgets() statt bekommt()

char buffer[BUFSIZ]; 
/* gets(buffer); */ 
fgets(buffer,sizeof(buffer), stdin); 

Die gets() Funktion, um die Länge der Puffer nicht überprüft, und kann über das Ende schreiben und den Stapel verändern. Dies ist der "Pufferüberlauf", von dem Sie hören.

5

Sie sollten die gets Funktion überhaupt nicht verwenden, die Hilfeseite sagt stattdessen fgets zu verwenden.

GCC bietet nicht die Funktionalität, die GCC zum Deaktivieren von Warnungen mit Pragmas bietet. Sie müssen stattdessen die verschiedenen warning options als Flags für den Compiler verwenden.

+0

Diese Warnung wird vom Linker gegeben. Ich kenne keine Möglichkeit, es zu deaktivieren. – AProgrammer

6

Es gibt wirklich keinen guten Grund, gets() zu verwenden. Selbst der C-Standard sagt, es ist veraltet! Verwenden Sie stattdessen fgets().

[Bearbeiten]

Es sieht aus wie die Warnung von dem Linker kommt. Wird beim Kompilieren mit -c eine Warnung ausgegeben? (Das deaktiviert Verknüpfung.)

24

Wenn Sie es wirklich verwenden möchten.Hier

ist Antwort Von: http://www.gamedev.net/community/forums/topic.asp?topic_id=523641

Wenn Sie eine einigermaßen aktuelle Version von gcc verwenden, können Sie verwenden:

#pragma GCC diagnostic ignored "your option here" 

Zum Beispiel, wenn diese Header ein „Floating-Point-Vergleich ist unsicher“ produzieren Fehler, verwenden Sie:

#pragma GCC diagnostic ignored "-Wfloat-equal". 

Unluckily, können Sie nicht deaktivieren „-Wall“ auf diese Weise (das wäre zu einfach, wäre es nicht ...), müssen Sie die einzelnen Krieg tun Optionen, die -Wall von Hand (zumindest die Konfliktparteien) ermöglicht.

Docs: http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas

EDIT: Aber es wird Warnung nicht funktionieren scheint ... habe ich versucht, auf meinem PC.

+3

+1 Obwohl ich zustimme, dass gets() nicht verwendet werden muss, bist du der einzige, der OPs Frage beantwortet hat :) – qrdl

+4

Das funktioniert nur für die Diagnose, die vom * Compiler * ausgegeben wird. Die Nachricht "Gets is unsafe" kommt vom * Linker * und AFAIK gibt es keine Möglichkeit, sie zu deaktivieren. – zwol

-2

Entgegen der landläufigen Meinung sind nicht alle Programmierer gleichermaßen unaufmerksam zu dem, was sie schreiben. gets() wird immer Standard in C90 sein, und es wurde aus mehreren guten Gründen in die Bibliothek gestellt. Es ist nicht mehr „gefährlich“ als jede andere String-Funktion, wenn in geeigneter Weise, wie in Programmbeispiele, Dokumentation, Unit-Test-Gerüsten, Hausaufgaben, etc. verwendet

Was mehr ist, gets() verbessert die Lesbarkeit in einer Weise, dass fgets() nie. Und man muss niemals seinen Gedankengang unterbrechen, um nachzusehen, in welcher Reihenfolge seine Argumente eingefügt werden sollen.

Die folgende Problemumgehung verwendet meine andere bevorzugte Funktion, um den Zeilenumbruch zu entfernen. :)

#define gets GET_LOST 
#include "stdio.h" 
#undef gets 

#include "limits.h" 

char *gets(char *s) 
{ 
    return strtok(fgets(s, INT_MAX, stdin), "\n"); 
} 
+8

Wer unterschreibt eine SO-Antwort mit ihrem Namen, ihrer Telefonnummer und einem Datum? – bgw

+0

Wenn Benutzereingaben nur aus "\ n" bestehen, gibt diese Routine "NULL" zurück. Original 'gets()' return '" "'. – chux

1

Schlagen Sie einen sicheren Ersatz für gets() vor.

In bestehendem Code, gets() zu ersetzen, ist es nicht erwünscht sein kann fgets() zu verwenden, da diese Funktion einen zusätzlichen char erfordert die '\n' zu speichern, die beiden Funktionen verbrauchen, aber gets() spart nicht. Folgendes ist ein Ersatz, der keine größere Puffergröße erfordert.

Jeder gets(dest) ist ersetzen mit:
Wenn dest ein Array ist, verwenden gets_sz(dest, sizeof dest)
Wenn dest ein Zeiger auf ein char Array der Größe ist n, verwenden gets_sz(dest, n)

char *gets_sz(char *dest, size_t size) { 
    if (size <= 1) { 
     if (size <= 0 || feof(stdin)) { 
      return NULL; 
     } 
    } 
    size--; 
    size_t i; 
    for (i = 0; i < size; i++) { 
     int ch = getchar(); 
     if (ch == EOF) { 
      if (i == 0) 
       return NULL; 
      break; 
     } 
     if (ch == '\n') 
      break; 
     dest[i] = (char) ch; 
    } 
    dest[i] = 0; 
    return dest; 
} 
0

Wenn Sie wirklich verwenden möchten Versuchen Sie es mit der Flagge -fsyntax-only.

Das Handbuch in gcc website sagt:

-fsyntax-only

Check the code for syntax errors, but don't do anything beyond that.