Oui c’est bien un comportement indéfini.
Pour la source, il suffit d’aller voir le standard.
Si on va voir la norme du C99 (AFAIK ça n’a pas changé en C11), ISO/IEC 9899:TC3 section 6.5.3.2/4:
If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined(87).
La note de bas de page 87 nous dit
Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime
Donc déréférencer un pointeur NULL c’est un UB.
Ça va même plus loin en fait, tu peux faire très peu de choses avec un pointeur NULL (avec les pointeurs invalides de manière générale en fait) : toute opération arithmétique avec un pointeur NULL débouche sur un UB.
Oui, même faire NULL - NULL c’est un comportement indéfini en C :D
Point intéressant à noter, le C++ diffère là dessus : il définit le résultat de certaines opérations arithmétiques sur NULL (voir cet article pour les explications du « pourquoi »).
[^] # Re: Comportement attendu
Posté par grim7reaper . En réponse au journal Compilateur trop intelligent. Évalué à 7.
Oui c’est bien un comportement indéfini.
Pour la source, il suffit d’aller voir le standard.
Si on va voir la norme du C99 (AFAIK ça n’a pas changé en C11), ISO/IEC 9899:TC3 section 6.5.3.2/4:
La note de bas de page 87 nous dit
Donc déréférencer un pointeur
NULLc’est un UB.Ça va même plus loin en fait, tu peux faire très peu de choses avec un pointeur
NULL(avec les pointeurs invalides de manière générale en fait) : toute opération arithmétique avec un pointeurNULLdébouche sur un UB.Oui, même faire
NULL - NULLc’est un comportement indéfini en C :DPoint intéressant à noter, le C++ diffère là dessus : il définit le résultat de certaines opérations arithmétiques sur
NULL(voir cet article pour les explications du « pourquoi »).