Perché non posso usare strerror?

Question

Sto eseguendo il porting di codice su Windows e il compilatore Microsoft (Visual C++ 8) mi sta dicendo che strerror() non è sicuro.

Mettendo da parte il fattore di disturbo in tutte le risorse di stringa sicure da Microsoft, posso effettivamente vedere che alcune delle funzioni deprecate sono pericolose. Ma non riesco a capire cosa potrebbe essere sbagliato con strerror(). Prende un codice (int) e restituisce la stringa corrispondente o la stringa vuota se tale codice non è noto.

Dov'è il pericolo?

Esiste una buona alternativa in C?

Esiste una buona alternativa in C++?

[modifica]

Avendo ottenuto alcune buone risposte, e ora comprendere che alcune implementazioni possono essere così pazzo da scrivere in realtà ad un buffer comune condiviso - pericoloso per rientranza all'interno di un singolo thread, figuriamoci tra i thread! - la mia domanda smette di essere "Perché non posso usarla e quali sono le alternative?" a "Esistono alternative decenti e succinte in C e/o C++?"

Grazie in anticipo

Answer 1

strerror è deprecato, perché non è thread-safe. strerror funziona su un buffer statico interno, che può essere sovrascritto da altri thread concorrenti. È necessario utilizzare una variante sicura denominata strerror_s.

La variante protetta richiede che la dimensione del buffer venga passata alla funzione per verificare che il buffer sia sufficientemente grande prima di scriverlo, aiutando a evitare sovraccarichi del buffer che potrebbero consentire l'esecuzione di codice dannoso.

Answer 2

Non è possibile fare affidamento sulla stringa restituita da strerror() perché potrebbe cambiare con la chiamata successiva alla funzione. I valori precedentemente restituiti potrebbero diventare obsoleti. Soprattutto negli ambienti multi-thread , non è possibile garantire che la stringa sia valida quando ci si accede.

Immaginate questo:

Thread #1: 
char * error = strerror(1); 
            Thread #2 
            char * error = strerror(2); 
printf(error); 

seconda dell'implementazione di strerror(), questo codice stampa il codice di errore per il codice di errore 2, non per il codice di errore 1.

Answer 3

Anche se io non conosco le ragioni di Microsoft , Noto che lo strerror restituisce un carattere non const *, il che significa che c'è il rischio che qualche Merry Prankster abbia chiamato strerror prima di averlo fatto e modificato il messaggio.

Answer 4

strerror da solo non è pericoloso. Nei tempi passati prima di infilare semplicemente non era un problema. Con i thread, due o più thread possono chiamare strerror lasciando il buffer restituito in uno stato indefinito. Per i programmi a thread singolo non dovrebbe fare male usare strerror a meno che non stiano giocando alcuni giochi bizzarri in libc, come la memoria comune per tutte le app in una DLL.

per affrontare questo c'è una nuova interfaccia per la stessa funzionalità:

int strerror_r(int errnum, char *buf, size_t buflen); 

Nota che il chiamante fornisce lo spazio buffer e la dimensione del buffer. Questo risolve il problema. Anche per le applicazioni a thread singolo si potrebbe anche usarlo. Non farà male un po ', e potresti anche abituarti a farlo in modo più sicuro.

NOTA: il prototipo sopra riportato è la specifica XSI. Può variare a seconda della piattaforma o con opzioni del compilatore o simboli #define. GNU, per esempio, fa si che o la loro propria versione disponibile a seconda di una #define

Answer 5

Per un wrapper succinta, è possibile utilizzare STLSoft s' stlsoft::error_desc, come in:

std::string errstr = stlsoft::error_desc(errno); 

Guardando il codice, sembra che è implementato in termini di strerror(), il che significa che sarà sicuro per la rientranza all'interno di un thread (cioè se utilizzato più volte all'interno di una determinata istruzione), ma non risolve il problema del multithreading.

Sembrano operare cicli di rilascio piuttosto rapidi per difetti, quindi potresti provare a richiedere una mod?

Answer 6

Avendo ottenuto alcune buone risposte, e ora comprendere che alcune implementazioni possono essere così pazzo da scrivere in realtà ad un buffer comune condiviso - pericoloso per rientranza all'interno di un singolo thread, figuriamoci tra i thread! - la mia domanda smette di essere "Perché non posso usarla e quali sono le alternative?" a "Esistono alternative decenti e succinte in C e/o C++?"

Posix specifica strerror_r(), e su Windows è possibile utilizzare strerror_s(), che è un po 'diverso, ma ha lo stesso obiettivo. Faccio questo:

#define BAS_PERROR(msg, err_code)\ 
    bas_perror(msg, err_code, __FILE__, __LINE__) 

void bas_perror (const char* msg, int err_code, const char* filename, 
       unsigned long line_number); 


void 
bas_perror (const char* usr_msg, int err_code, const char* filename, 
      unsigned long line_number) 
{ 
    char sys_msg[64]; 

#ifdef _WIN32 
    if (strerror_s(sys_msg, sizeof sys_msg, err_code) != 0) 
    { 
    strncpy(sys_msg, "Unknown error", taille); 
    sys_msg[sizeof sys_msg - 1] = '\0'; 
    } 
#else 
    if (strerror_r(err_code, sys_msg, sizeof sys_msg) != 0) 
    { 
    strncpy(sys_msg, "Unknown error", sizeof sys_msg); 
    sys_msg[sizeof sys_msg - 1] = '\0'; 
    } 
#endif 

    fprintf(stderr, "%s: %s (debug information: file %s, at line %lu)\n", 
      usr_msg, sys_msg, filename, line_number); 
} 

Ho scritto questa funzione perché thread POSIX funzioni non modificano errno, ritornano un codice di errore invece. Quindi questa funzione è fondamentalmente uguale a perror(), tranne per il fatto che consente di fornire un codice di errore diverso da errno e visualizza anche alcune informazioni di debug. Puoi adattarlo alle tue necessità.