Pourquoi la fin d'une fonction non void sans renvoyer une valeur ne produit-elle pas une erreur du compilateur?

Depuis que j'ai réalisé il y a de nombreuses années, que cela ne produisait pas d'erreur par défaut (au moins dans GCC), je me suis toujours demandé pourquoi?

Je comprends que vous pouvez émettre des indicateurs de compilateur pour produire un avertissement, mais cela ne devrait-il pas toujours être une erreur? Pourquoi est-il logique qu'une fonction non vide ne renvoyant pas de valeur soit valide?

Un exemple comme demandé dans les commentaires:

#include <stdio.h>
int stringSize()
{
}

int main()
{
    char cstring[5];
    printf( "the last char is: %c\n", cstring[stringSize()-1] ); 
    return 0;
}

... compile.

Les normes C99 et C ++ n'exigent pas que les fonctions retournent une valeur. L'instruction de retour manquante dans une fonction de retour de valeur sera définie (à renvoyer 0) uniquement dans la mainfonction.

La justification inclut que vérifier si chaque chemin de code renvoie une valeur est assez difficile, et une valeur de retour pourrait être définie avec l'assembleur intégré ou d'autres méthodes délicates.

À partir du brouillon C ++ 11 :

§ 6.6.3 / 2

L'écoulement de la fin d'une fonction [...] entraîne un comportement indéfini dans une fonction de retour de valeur.

§ 3.6.1 / 5

Si le contrôle atteint la fin de mainsans rencontrer d' return instruction, l'effet est celui de l'exécution

return 0;

Notez que le comportement décrit dans C ++ 6.6.3 / 2 n'est pas le même en C.

gcc vous donnera un avertissement si vous l'appelez avec l'option -Wreturn-type.

-Wreturn-type Avertir chaque fois qu'une fonction est définie avec un type de retour qui vaut par défaut int. Avertissez également de toute instruction de retour sans valeur de retour dans une fonction dont le type de retour n'est pas void (tomber la fin du corps de la fonction est considéré comme retournant sans valeur), et d'une instruction de retour avec une expression dans une fonction dont return-type est nul.

Cet avertissement est activé par -Wall .

Juste par curiosité, regardez ce que fait ce code:

#include <iostream>

int foo() {
   int a = 5;
   int b = a + 1;
}

int main() { std::cout << foo() << std::endl; } // may print 6

Ce code a un comportement formellement non défini et, en pratique, il appelle la convention et l' architecture dépendante. Sur un système particulier, avec un compilateur particulier, la valeur de retour est le résultat de la dernière évaluation d'expression, stockée dans le eaxregistre du processeur de ce système.

gcc ne vérifie pas par défaut que tous les chemins de code renvoient une valeur car en général cela ne peut pas être fait. Cela suppose que vous savez ce que vous faites. Prenons un exemple courant utilisant des énumérations:

Color getColor(Suit suit) {
    switch (suit) {
        case HEARTS: case DIAMONDS: return RED;
        case SPADES: case CLUBS:    return BLACK;
    }

    // Error, no return?
}

Vous le programmeur savez que, sauf bogue, cette méthode renvoie toujours une couleur. gcc croit que vous savez ce que vous faites afin de ne pas vous obliger à mettre un retour au bas de la fonction.

javac, d'autre part, essaie de vérifier que tous les chemins de code renvoient une valeur et renvoie une erreur s'il ne peut pas prouver qu'ils le font tous. Cette erreur est imposée par la spécification du langage Java. Notez que parfois c'est faux et que vous devez mettre une déclaration de retour inutile.

char getChoice() {
    int ch = read();

    if (ch == -1 || ch == 'q') {
        System.exit(0);
    }
    else {
        return (char) ch;
    }

    // Cannot reach here, but still an error.
}

C'est une différence philosophique. C et C ++ sont des langages plus permissifs et plus fiables que Java ou C # et certaines erreurs dans les nouveaux langages sont des avertissements en C / C ++ et certains avertissements sont ignorés ou désactivés par défaut.

Vous voulez dire, pourquoi sortir de la fin d'une fonction de retour de valeur (c'est-à-dire sortir sans explicite return) n'est pas une erreur?

Premièrement, en C, le fait qu'une fonction retourne quelque chose de significatif ou non n'est critique que lorsque le code en cours d'exécution utilise réellement la valeur retournée. Peut-être que la langue ne voulait pas vous forcer à renvoyer quoi que ce soit quand vous savez que vous n'allez pas l'utiliser de toute façon la plupart du temps.

Deuxièmement, apparemment, la spécification du langage ne voulait pas forcer les auteurs du compilateur à détecter et à vérifier tous les chemins de contrôle possibles pour la présence d'un explicite return(bien que dans de nombreux cas ce ne soit pas si difficile à faire). De plus, certains chemins de contrôle peuvent conduire à des fonctions non retournées - le trait généralement inconnu du compilateur. De tels chemins peuvent devenir une source de faux positifs ennuyeux.

Notez également que C et C ++ diffèrent dans leurs définitions du comportement dans ce cas. En C ++, le simple fait d'écouler la fin d'une fonction retournant une valeur est toujours un comportement indéfini (indépendamment du fait que le résultat de la fonction soit utilisé par le code appelant). En C, cela provoque un comportement indéfini uniquement si le code appelant essaie d'utiliser la valeur renvoyée.

Il est légal sous C / C ++ de ne pas revenir d'une fonction qui prétend retourner quelque chose. Il existe un certain nombre de cas d'utilisation, tels que l'appel exit(-1)ou une fonction qui l'appelle ou lève une exception.

Le compilateur ne rejettera pas le C ++ légal même s'il conduit à UB si vous lui demandez de ne pas le faire. En particulier, vous demandez qu'aucun avertissement ne soit généré. (Gcc en active toujours certains par défaut, mais une fois ajoutés, ceux-ci semblent correspondre aux nouvelles fonctionnalités et non aux nouveaux avertissements pour les anciennes fonctionnalités)

Changer le gcc no-arg par défaut pour émettre des avertissements pourrait être un changement radical pour les scripts existants ou créer des systèmes. Ceux qui sont bien conçus -Wallet traitent les avertissements ou basculent les avertissements individuels.

Apprendre à utiliser une chaîne d'outils C ++ est un obstacle à l'apprentissage du programmeur C ++, mais les chaînes d'outils C ++ sont généralement écrites par et pour des experts.

Je pense que c'est à cause du code hérité (C n'a jamais requis de déclaration de retour, tout comme C ++). Il existe probablement une énorme base de code reposant sur cette «fonctionnalité». Mais au moins il y a un -Werror=return-type drapeau sur de nombreux compilateurs (y compris gcc et clang).

Dans certains cas limités et rares, la sortie de la fin d'une fonction non vide sans renvoyer une valeur peut être utile. Comme le code spécifique MSVC suivant:

double pi()
{
    __asm fldpi
}

Cette fonction renvoie pi en utilisant l'assembly x86. Contrairement à l'assemblage dans GCC, je ne connais aucun moyen d'utiliserreturn pour faire cela sans impliquer des frais généraux dans le résultat.

Autant que je sache, les compilateurs C ++ traditionnels devraient émettre au moins des avertissements pour un code apparemment invalide. Si je fais le corps depi() vide, GCC / Clang rapportera un avertissement, et MSVC rapportera une erreur.

Les gens ont mentionné des exceptions et exitdans certaines réponses. Ce ne sont pas des raisons valables. Le fait de lever une exception ou d'appeler neexit fera pas que l'exécution de la fonction se termine. Et les compilateurs le savent: écrire une instruction throw ou appeler exitle corps vide de pi()arrêtera tout avertissement ou erreur d'un compilateur.

Dans quelles circonstances cela ne produit-il pas une erreur? S'il déclare un type de retour et ne renvoie rien, cela me semble être une erreur.

La seule exception à laquelle je peux penser est la main()fonction, qui n'a pas du tout besoin d'une returndéclaration (au moins en C ++; je n'ai aucune des normes C à portée de main). S'il n'y a pas de retour, il agira comme si c'était return 0;la dernière instruction.

On dirait que vous devez activer les avertissements de votre compilateur:

$ gcc -Wall -Wextra -Werror -x c -
int main(void) { return; }
cc1: warnings being treated as errors
<stdin>: In function ‘main’:
<stdin>:1: warning: ‘return’ with no value, in function returning non-void
<stdin>:1: warning: control reaches end of non-void function
$

Il s'agit d'une violation de contrainte dans c99, mais pas dans c89. Contraste:

c89:

3.6.6.4 Le return déclaration

Contraintes

Une returninstruction avec une expression ne doit pas apparaître dans une fonction dont le type de retour est void.

c99:

6.8.6.4 La returndéclaration

Contraintes

Une returninstruction avec une expression ne doit pas apparaître dans une fonction dont le type de retour est void. Une returninstruction sans expression n'apparaîtra que dans une fonction dont le type de retour est void.

Même en --std=c99mode, gcc ne lancera qu'un avertissement (bien que sans avoir besoin d'activer des -Windicateurs supplémentaires , comme cela est requis par défaut ou dans c89 / 90).

Modifier pour ajouter qu'en c89, "atteindre le }qui termine une fonction équivaut à exécuter une returninstruction sans expression" (3.6.6.4). Cependant, dans c99, le comportement n'est pas défini (6.9.1).