se uno si lamenta di gets(), perché non fare lo stesso con scanf ("% s", ...)?

Question

Da man gets:

Non utilizzare mai gets(). Perché è impossibile dire senza conoscere i dati in anticipo quanti caratteri gets() leggerà, e perché gets() continuerà a memorizzare caratteri oltre la fine del buffer, è estremamente pericoloso usare . È stato utilizzato per interrompere la sicurezza del computer . Usa invece fgets().

Quasi ovunque vedo scanf in uso in un modo che dovrebbe avere lo stesso problema (buffer overflow/buffer overrun): scanf("%s",string). Questo problema esiste in questo caso? Perché non ci sono riferimenti a riguardo nella pagina man scanf? Perché gcc non avvisa quando si compila questo con -Wall?

ps: so che c'è un modo per specificare nella stringa di formato la lunghezza massima della stringa con scanf:

char str[10]; 
scanf("%9s",str); 

edit: io non chiedo di Determe se il codice precedente è giusto o non. La mia domanda è: se scanf("%s",string) è sempre sbagliato, perché non ci sono avvisi e non c'è nulla al riguardo nella pagina man?

Answer 1

La risposta è semplicemente che nessuno ha scritto il codice in GCC per produrre tale avviso.

Come si fa notare, un avviso per il caso specifico di "%s" (senza larghezza di campo) è appropriato.

Tuttavia, tenere presente che questo è solo il caso per il caso di scanf(), vscanf(), fscanf() e vfscanf(). Questo identificatore di formato può essere perfettamente sicuro con sscanf() e vsscanf(), quindi l'avviso non dovrebbe essere emesso in quel caso. Ciò significa che non puoi semplicemente aggiungerlo al codice di analisi "scanf-style-format-string" esistente; dovrai dividerlo in opzioni "fscanf-style-format-string" e "sscanf-style-format-string".

Sono sicuro che se si produce una patch per l'ultima versione di GCC ha buone probabilità di essere accettata (e, naturalmente, sarà necessario inviare patch anche per i file di intestazione glibc).

Answer 2

L'utilizzo di gets() non è mai sicuro. scanf() può essere usato in modo sicuro, come hai detto nella tua domanda. Tuttavia, determinare se lo stai usando in modo sicuro è un problema più difficile da risolvere (ad esempio se stai chiamando scanf() in una funzione in cui passi il buffer e un numero di caratteri come argomenti, non sarà capace di dire); in tal caso, deve presumere di sapere cosa stai facendo.

Answer 3

Potrebbe essere semplicemente che scanf allocherà spazio sull'heap in base alla quantità di dati letti. Poiché non alloca il buffer e quindi legge finché non viene letto il carattere null, non rischia di sovrascrivere il buffer. Invece, legge nel proprio buffer fino a quando viene trovato il carattere null e presumibilmente copia quel buffer in un altro della dimensione corretta alla fine della lettura.

Answer 4

Quando il compilatore esamina la stringa di formattazione di scanf, vede una stringa! Questo presuppone che la stringa di formattazione non venga inserita in fase di esecuzione. Alcuni compilatori come GCC hanno alcune funzionalità extra per analizzare la stringa di formattazione se inseriti in fase di compilazione. Questa funzionalità aggiuntiva non è completa, poiché in alcune situazioni è necessario un sovraccarico di run-time NO NO per le lingue come C. Ad esempio, puoi rilevare un utilizzo non sicuro senza inserire alcun codice nascosto aggiuntivo in questo caso:

char* str; 
size_t size; 
scanf("%z", &size); 
str = malloc(size); 
scanf("%9s"); // how can the compiler determine if this is a safe call?! 

Ovviamente esistono modi per scrivere codice sicuro con scanf se si specifica il numero di caratteri da leggere e che è presente memoria sufficiente per contenere la stringa. Nel caso di gets, non è possibile specificare il numero di caratteri da leggere.

Answer 5

Non sono sicuro del motivo per cui la pagina man per scanf non menziona la probabilità di un sovraccarico del buffer, ma vanilla scanf non è un'opzione sicura. Un collegamento piuttosto datato - http://blogs.msdn.com/b/rsamona/archive/2005/10/24/484449.aspx mostra questo come il caso.Inoltre, controlla questo (non gcc ma comunque informativo) - http://blogs.msdn.com/b/parthas/archive/2006/12/06/application-crash-on-replacing-sscanf-with-sscanf-s.aspx