sprintf_s con un buffer troppo piccolo

Question

Il seguente codice causa un errore e uccide la mia applicazione. Ha senso poiché il buffer ha una lunghezza di soli 10 byte e il testo è lungo 22 byte (buffer overflow).

char buffer[10];  
int length = sprintf_s(buffer, 10, "1234567890.1234567890."); 

Come faccio a prendere questo errore in modo da poter segnalare invece di schiantarsi la mia domanda?

Edit:

Dopo aver letto le commenti qui sotto sono andato con _snprintf_s. Se restituisce un valore -1, il buffer non è stato aggiornato.

length = _snprintf_s(buffer, 10, 9, "123456789"); 
printf("1) Length=%d\n", length); // Length == 9 

length = _snprintf_s(buffer, 10, 9, "1234567890.1234567890."); 
printf("2) Length=%d\n", length); // Length == -1 

length = _snprintf_s(buffer, 10, 10, "1234567890.1234567890."); 
printf("3) Length=%d\n", length); // Crash, it needs room for the NULL char 

Answer 1

Invece di sprintf_s, è possibile utilizzare snprintf (a.k.a _snprintf su Windows).

#ifdef WIN32 
#define snprintf _snprintf 
#endif 

char buffer[10];  
int length = snprintf(buffer, 10, "1234567890.1234567890."); 
// unix snprintf returns length output would actually require; 
// windows _snprintf returns actual output length if output fits, else negative 
if (length >= sizeof(buffer) || length<0) 
{ 
    /* error handling */ 
} 

Answer 2

Da MSDN:

L'altra differenza principale tra sprintf_s e sprintf è che sprintf_s un parametro di lunghezza specifica la dimensione del buffer di uscita in caratteri. Se il buffer è troppo piccolo per il testo che viene stampato, il buffer viene impostato su una stringa vuota e viene invocato il gestore parametri non valido. Diversamente da snprintf, sprintf_s garantisce che il buffer sarà terminato con null (a meno che la dimensione del buffer non sia zero).

Quindi idealmente quello che hai scritto dovrebbe funzionare correttamente.

Answer 3

Sembra che tu stia scrivendo su MSVC di qualche tipo?

Penso che i documenti MSDN per sprintf_s dicano che asserisce muore, quindi non sono sicuro di poterlo prendere a livello di codice.

Come suggerito da LBushkin, è molto meglio usare le classi che gestiscono le stringhe.

Answer 4

È di progettazione. L'intero punto di sprintf_s e altre funzioni della famiglia *_s consiste nel rilevare gli errori di sovraccarico del buffer e trattarli come violazioni di precondizione . Ciò significa che non sono pensati per essere recuperabili. Questo è progettato per catturare solo gli errori - non si dovrebbe mai chiamare sprintf_s se si sa che la stringa può essere troppo grande per un buffer di destinazione. In tal caso, utilizzare prima strlen per verificare e decidere se è necessario tagliare.

Answer 5

Vedere la sezione 6.6.1 di TR24731 che è la versione ISO C Committee della funzionalità implementata da Microsoft. Fornisce funzioni set_constraint_handler(), abort_constraint_handler() e ignore_constraint_handler() funzioni.

Ci sono commenti da Pavel Minaev che suggeriscono che l'implementazione di Microsoft non aderisce alla proposta TR24731 (che è un "Rapporto tecnico di tipo 2"), quindi potresti non essere in grado di intervenire, o potresti dover fare qualcosa diverso da quello che il TR indica dovrebbe essere fatto. Per questo, scruta MSDN.

Answer 6

Questo funziona con VC++ ed è ancora più sicuro che usare snprintf (e certamente più sicuro di _snprintf):

void TestString(const char* pEvil) 
{ 
    char buffer[100]; 
    _snprintf_s(buffer, _TRUNCATE, "Some data: %s\n", pEvil); 
} 

Il _TRUNCATE flag indica che la stringa dovrebbe essere troncato. In questa forma la dimensione del buffer non viene effettivamente passata, cosa che (paradossalmente!) è ciò che lo rende così sicuro. Il compilatore utilizza la magia del template per dedurre la dimensione del buffer, il che significa che non può essere specificato in modo errato (un errore sorprendentemente comune). Questa tecnica può essere applicata per creare altri wrapper di string sicure, come descritto nel post del mio blog qui: https://randomascii.wordpress.com/2013/04/03/stop-using-strncpy-already/