L'absence d'une inclusion obligatoire est-elle un comportement indéfini ?

Question

Comme je l'ai écrit dans une réponse à Comment est-il possible d'utiliser pow sans inclure la bibliothèque cmath ? Je crains d'avoir prouvé que l'absence d'inclusion d'un en-tête nécessaire est en fait un comportement non défini, mais comme je n'ai trouvé aucun consentement de ce fait, j'aime imposer la question formelle :

Il manque un en-tête obligatoire, par exemple

#include <iostream>

int main()
{
    std::cout << std::pow(10, 2);
}

1. Un code mal formé ([defns.ill.formed]) ?
2. Invoquer un comportement non défini ( [defns.undefined] ) ?
3. Si ce n'est pas 1 et 2, s'agit-il d'un comportement non spécifié [defns.unspecified] ou d'un comportement défini par l'implémentation [defns.impl.defined] ?
4. Si ce n'est pas 1, c'est-à-dire si ce code est bien formé, cela ne contredirait-il pas [using.headers] et [intro.compliance] "accepter et exécuter correctement un programme bien formé" ?

Comme dans mon réponse J'ai tendance à répondre par l'affirmative à ces deux questions, mais [using.headers] est très déroutant à cause de Différence entre un comportement non défini et un comportement mal formé, pas de message de diagnostic nécessaire . Comme [defns.well.formed] implique qu'un programme construit selon l'ODR est bien formé, et qu'il y a une spécification de chaque fois que le par exemple iostream ne doit pas définir pow On pourrait dire qu'il s'agit toujours d'un comportement non spécifié ([defns.unspecified]). Je ne veux pas me fier uniquement à mes compétences en matière d'interprétation standard pour obtenir une réponse définitive à une question aussi importante. Notez que la réponse acceptée, c'est-à-dire la seule autre réponse, ne permet pas de savoir si le code est UB et la question ne le demande pas.

Answer 1

Il est non spécifié si ce programme est bien formé ou mal formé (avec un diagnostic obligatoire, car la recherche par nom ne trouve pas pow ). Les possibilités découlent de l'affirmation selon laquelle un en-tête C++ peut inclure un autre qui accorde autorisation à la mise en œuvre pour donner à ce programme l'une ou l'autre des deux interprétations possibles.

Plusieurs règles similaires ( par exemple (qu'un modèle doit avoir au moins une spécialisation potentielle valide) sont La liberté de choix est décrite comme rendant le programme mal formé, aucun diagnostic n'est requis, mais dans cette situation, cette liberté n'est pas étendue à l'implémentation (ce qui est sans doute préférable). Cela dit, une implémentation est de traiter un programme mal formaté dans un arbitraire tant qu'il émet au moins un message de diagnostic, il n'est donc pas complètement déraisonnable de regrouper cette situation avec un véritable comportement non défini, même si les symptômes diffèrent utilement dans la pratique.