Costruisci eccezioni standard con argomento puntatore null e postcondizioni impossibili

Considera il seguente programma:

#include<stdexcept>
#include<iostream>

int main() {
    try {
        throw std::range_error(nullptr);
    } catch(const std::range_error&) {
        std::cout << "Caught!\n";
    }
}

GCC e Clang con libstdc ++ chiamano std::terminatee interrompono il programma con il messaggio

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid

Clang con libc ++ segfaults alla costruzione dell'eccezione.

Vedi godbolt .

I compilatori si comportano secondo standard? La sezione pertinente dello standard [diagnostics.range.error] (C ++ 17 N4659) afferma che std::range_errorha un const char*sovraccarico del costruttore che dovrebbe essere preferito rispetto al const std::string&sovraccarico. La sezione inoltre non indica alcuna condizione preliminare per il costruttore e indica solo la postcondizione

Postcondizioni : strcmp(what(), what_­arg) == 0.

Questa postcondizione ha sempre un comportamento indefinito se what_argè un puntatore nullo, quindi questo significa che anche il mio programma ha un comportamento indefinito e che entrambi i compilatori agiscono in modo conforme? In caso contrario, come si dovrebbero leggere tali postcondizioni impossibili nello standard?

A pensarci bene, penso che debba significare un comportamento indefinito per il mio programma, perché se non lo facesse allora anche i puntatori (validi) che non puntano a stringhe con terminazione nulla sarebbero ammessi, il che chiaramente non ha senso.

Quindi, supponendo che sia vero, vorrei focalizzare maggiormente la domanda su come lo standard implichi questo comportamento indefinito. Dall'impossibilità della postcondizione deriva che anche la chiamata ha un comportamento indefinito o la precondizione è stata semplicemente dimenticata?

Ispirato da questa domanda .

Dal documento :

Poiché la copia di std :: range_error non è autorizzata a generare eccezioni, questo messaggio viene in genere archiviato internamente come stringa conteggio dei riferimenti allocata separatamente. Questo è anche il motivo per cui nessun costruttore prende std :: string &&: dovrebbe comunque copiare il contenuto.

Questo dimostra perché diventi segfault, l'API lo tratta davvero come una vera stringa. In generale in cpp se qualcosa fosse facoltativo, ci sarà un costruttore / funzione sovraccarico che non accetta ciò di cui non ha bisogno. Quindi passare nullptrper una funzione che non documenta qualcosa di facoltativo sarà un comportamento indefinito. Di solito le API non accettano i puntatori, ad eccezione delle stringhe C. Quindi, IMHO è sicuro supporre che passare nullptr per una funzione che si aspetta un const char *, sia un comportamento indefinito. Le API più recenti potrebbero preferire std::string_viewper questi casi.

Aggiornare:

Di solito è giusto supporre che un'API C ++ prenda un puntatore per accettare NULL. Tuttavia, le stringhe C sono un caso speciale. Fino a quando std::string_viewnon c'era modo migliore per passarli in modo efficiente. In generale per un'accettazione dell'API const char *, si suppone che debba essere una stringa C valida. cioè un puntatore a una sequenza di chars che termina con un '\ 0'.

range_errorpotrebbe validare che il puntatore non lo è nullptrma non può validare se termina con uno '\ 0'. Quindi è meglio non effettuare alcuna convalida.

Non conosco la formulazione esatta nello standard, ma questa pre-condizione è probabilmente assunta automaticamente.

Questo torna alla domanda di base è OK per creare uno std :: string da nullptr? e cosa dovrebbe fare?

www.cplusplus.com dice

Se s è un puntatore nullo, se n == npos o se l'intervallo specificato da [primo, ultimo) non è valido, provoca un comportamento indefinito.

Cosi quando

throw std::range_error(nullptr);

si chiama l'implementazione cerca di creare qualcosa di simile

store = std::make_shared<std::string>(nullptr);

che non è definito. Che considererei un bug (senza aver letto la formulazione effettiva nello standard). Invece gli sviluppatori di libery avrebbero potuto creare qualcosa di simile

if (what_arg)
  store = std::make_shared<std::string>(nullptr);

Ma poi il ricevitore deve controllare nullptr what();o si bloccherà lì. Quindi std::range_errordovrebbe assegnare una stringa vuota o "(nullptr)" come fanno alcune altre lingue.