quando si definiscono le costanti, #define è più sicuro di const statico?

3

Voglio avere alcuni valori costanti nel mio programma, ad esempio, ho un valore costante TimeLimit in un'intestazione che è comunemente usata in altre classi, ma non so se

#define TimeLimit 30

è più sicuro di

static const int TimeLimit=30;

Inizialmente voglio usare const statico perché può causare meno tempo di compilazione quando il valore è cambiato, ma dopo aver considerato la sicurezza sospetto che dovrei #define per migliorare la sicurezza.

è vero che #define è più sicuro di const statico perché:

  1. "# define" è incorporato nel codice compilato, mentre static int lascia una variabile in memoria, che un utente può modificare facilmente il valore di TimeLimit nel contenuto di memoria

  2. Se si utilizza const statico, è più facile per l'utente conoscere il valore di TimeLimit perché estrarre il valore dalla memoria è più semplice dell'estrazione dal codice compilato.

è giusto?

    
posta ggrr 15.01.2016 - 04:49
fonte

2 risposte

3

static const è più sicuro, ma non per i motivi a cui stai pensando. Permette al compilatore di eseguire il controllo dei tipi, che catturerà una classe di bug che #define non gli permetterà di catturare.

Riguardo alle tue preoccupazioni specifiche:

"#define" is embedded in compiled code, while static int leaves a variable in memory, which a user can change the value of TimeLimit in memory content easily

If using static const, it is easier for user to know the value of TimeLimit because extracting the value from memory is easier than extracting from compiled code.

In teoria, questo è vero. In pratica, ogni compilatore in uso corrente compilerà i due casi in modo identico (dare o prendere regole di inferenza di tipo). Nei miei test con GCC, sia un #define che un static const sono stati trasformati nel seguente assembly:

movl    $30, %eax

es. sposta il valore letterale 30 nel registro EAX in preparazione per eseguire un'operazione su di esso.

Ora, c'è un'eccezione a questo: se si sta compilando con le informazioni di debug, un valore static const potrebbe essere presente nelle informazioni di debug in cui una #define non lo sarà. Ma non dovresti distribuire versioni di software di debugging a nessuno di cui non ti fidi, o alla maggior parte delle persone di cui ti fidi.

    
risposta data 15.01.2016 - 09:49
fonte
0

Dalla mia comprensione, #define sostituirà effettivamente TimeLimit con il letterale 30 quando viene eseguito il preprocessore. Non mi è chiaro quale sia lo stato standard sulle variabili static const (se mai). Ad esempio, se il compilatore supporta la piegatura costante e la variabile viene utilizzata solo in espressioni costanti, le espressioni vengono valutate in fase di compilazione e non mi è chiaro se quella variabile sarà nel segmento di dati (globale) della memoria.

Immaginerei che se hai un avversario dedicato anche se ha accesso al tuo binario, sebbene sia in grado di decodificare questi valori. Penso che un'opzione migliore per le variabili sensibili potrebbe essere quella di usare std::getenv e memorizzare questi valori come variabili d'ambiente. Tuttavia, se l'avversario ha effettivamente accesso ai tuoi binari, può anche avere accesso alle tue variabili d'ambiente, quindi potresti voler chiarire il tuo modello di minaccia.

    
risposta data 15.01.2016 - 05:12
fonte

Leggi altre domande sui tag