Come risolvere il codice legacy che utilizza string.h non sicuro?

Question

Come risolvere il codice legacy che utilizza string.h non sicuro?

#1 da (6 voti)

4

Abbiamo un sacco di codice legacy, scritto in diritto C (alcuni dei quali è K & R!), che per molti, molti anni è stato compilato utilizzando Visual C 6.0 (circa 1998) su una macchina XP. Ci rendiamo conto che questo è insostenibile, e stiamo cercando di spostarlo in un compilatore moderno. I problemi politici hanno affermato che il compilatore più recente consentito è VC ++ 2005.

Durante la compilazione del progetto, ci sono molti avvertimenti sulle funzioni di manipolazione delle stringhe non sicure utilizzate ( sprintf() , strcpy() , ecc.). La revisione di alcuni di questi luoghi mostra che il codice è effettivamente pericoloso; non controlla i buffer overflow. L'avviso del compilatore consiglia di passare a sprintf_s() , strcpy_s() , ecc. Tuttavia, queste sono funzioni create da Microsoft (e proprietarie) e non sono disponibili su (diciamo) gcc (sebbene siamo principalmente un negozio Windows abbiamo alcuni client su vari tipi di * NIX)

Come dovremmo procedere? Non voglio caricare le nostre librerie di stringhe. Voglio solo andare oltre il codice una volta. Preferirei non passare a C ++ se possiamo aiutarlo.

c windows strings

posta Snowbody 24.08.2014 - 06:37

fonte

1 risposta

Leggi altre domande sui tag c windows strings

Java: come posso rendere il tipo di ritorno, di un metodo ereditato in una sottoclasse, lo stesso della sottoclasse? MVC: isolamento della vista e della logica del modello

score 6 · Accepted Answer

Innanzitutto, le funzioni "sicure" sono solo marginalmente più sicure delle funzioni che sostituiscono. Molte di queste funzioni "sicure" richiedono un parametro aggiuntivo che le informa della dimensione del buffer di destinazione (che usano per controllare gli overflow) e controllano che non vengano passati puntatori nulli dove non dovrebbero. Questo può rilevare alcuni errori, ma non tutti e potresti commettere un errore nel passaggio della dimensione del buffer sbagliata.

Se non vuoi passare alle funzioni sicure, o non puoi a causa dei requisiti di portabilità, allora ti consiglierei il seguente percorso:

Compilare il codice con Visual Studio con gli avvisi di deprecazione abilitati
Per ogni funzione di manipolazione delle stringhe che viene contrassegnata, valuta se c'è davvero la possibilità che venga passato un overflow del buffer o un puntatore nullo.
In caso di problemi potenziali, modifica il codice circostante per assicurarti che l'errore non si verifichi.
Quando sei sicuro che tutte le funzioni di gestione delle stringhe siano utilizzate il più possibile in modo sicuro, aggiungi al tuo Visual Studio una definizione _CRT_SECURE_NO_WARNINGS per sopprimere gli avvisi di deprecazione.

Poiché il codice è stato utilizzato con successo per un gran numero di anni, ho il sospetto che ci siano pochi posti con usi problematici delle funzioni di stringa.