Problemi nell'uso di srand() nelle librerie

C'è un ampio uso di chiamate srand()/rand() in librerie di terze parti, con semi predefiniti. Il problema sorge quando si combinano diverse librerie nello stesso processo. A volte è difficile garantire la giusta sequenza di chiamate, è possibile un mix di chiamate srand() e rand(). Un altro problema è l'incapacità di scegliere il valore di seeding a livello di applicazione. Come regola generale, dovremmo evitare di utilizzare srand() nelle librerie (incluso Open Source), lasciando l'attività di seeding alle applicazioni?Problemi nell'uso di srand() nelle librerie

fonte

2013-02-14 David Khosid

* O * si potrebbe usare un API casuale progettata in questo secolo, che doesn' si basano su un singolo seme * globale *. Realmente, 'rand()' è un'API orribile rotta, progettata male e implementata male. Se la tua biblioteca ha bisogno di un generatore casuale, usa una soluzione decente, che non compromette lo stato globale del processo. – jalf

Dal punto di vista della finestra di progettazione dell'applicazione, srand() nelle librerie open source è il mio problema. Non abbiamo nemmeno bisogno di casualità di grado di sicurezza. –

ogni libreria decente là fuori dovrebbe fare affidamento sull'utente effettivo per chiamare srand(). Se si utilizza roba di terze parti in cui viene chiamato srand(), si prega di dire loro che questa è una pessima pratica e rendere il mondo un posto migliore :) –

Se la libreria utilizza semi codificati, allora sì, DEVI avere un modo per cambiare quei semi in qualcosa che tu dichiari "abbastanza casuale" da essere un seme.

Anche se si utilizza una piattaforma che ha qualcosa come/dev/urand, probabilmente si potrebbe usare quello, o se si deve essere multipiattaforma perché non usare qualcosa come la libreria di numeri casuali di OpenSSL? Probabilmente OpenSSL dovrebbe essere disponibile su tutte le piattaforme che hai scelto come target e spesso è già installato, quindi devi solo collegarlo.

fonte

2013-02-14 20:07:46 Plecharts

In questa situazione, l'unico modo è modificare le librerie di terze parti. Complifica il facile spostamento verso le nuove versioni. –

@DavidKhosid Allora perché non cambiare la libreria se è scritta male? – Plecharts

In pratica, dobbiamo cercare in ogni libreria di terze parti questo difetto di progettazione (objdump), modificare la libreria per ogni versione che inseriamo nel progetto. Preferisco che le librerie non chiamino srand() incondizionatamente. –

Per le ragioni che hai citato, tra gli altri, è meglio la pratica in applicazioni reali di utilizzare boost::random o C++ 11 random biblioteca

fonte

2013-02-14 20:15:15 eladidan

La casualità del C++ 11 è ottima, concordo, ma le librerie di terze parti gestiscono da sole le casualità con le chiamate srand(). –

Non riesco a trovare alcuna fonte che confermi che boost :: random usa srand/rand. Potete fornire un riferimento a questo reclamo? – eladidan

Non ci sono problemi con boost :: random. C'è un problema con molte altre librerie open-source, per esempio ZLIB. –

Problemi nell'uso di srand() nelle librerie

risposta

Problemi correlati