Discussion :

[chris7522]

Bonjour a toutes et a tous ,
J'ai fait ce petit programme en m'inspirant d'un exemple ou l'auteur utilisait un return ... a chaque fin de fonction crée . Je les ai viré et ca fonctionne quand meme . Je me suis dit que c'est normal puisque lorsque je fait l'appel de mes fonctions , je place le resultat dans une variable . Donc , dans quel cas , ils est nécéssaire de faire un return machin chose ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#include <stdio.h>
#include <stdlib.h>
int nb_article();
int remise(int nb);
 
int main(){
 int nombre;
 int reduction;
 
 printf("Le prix du jean sans remise est de 30 euros\n");
 printf("10%% de remise entre 5 et 10 jeans acheté\n");
 printf("20%% de remise entre 10 et 100 jeans acheté\n");
 nombre=nb_article();
 printf("Vous avez séléctionné %d jeans\n",nombre);
 reduction=remise(nombre);
 printf("Le prix a l'unité sera de:%d Euros\n",reduction);
return 0;
}
 
int nb_article(){
 int article;
 do{
    printf("Combien d'article voulez vous?\n");
    scanf("%d",&article);
   }while(article<=4);
 
}
int remise(int nb){
 int prix=30;
 int reduc,op;
 if(nb>=5 && nb<=10){
  op=(prix*10)/100;
  reduc=prix-op;}
 if(nb>10 && nb<=100){
  op=(prix*20)/100;
  reduc=prix-op;}
}

[Bousk]

Ton truc compile parce que ton compilo est uuuultra souple, et encore.
Tu dois avoir des warning, qui ne doivent pas être ignorés.
Ou alors il ne compile pas du tout mais tu as une version précédente compilée qui se lance, et tu ignores la sortie qui t'indique ce comportement.

Si une fonction retourne quelque chose (donc non void), il faut bien un moment indiquer ce qu'elle doit retourner...
Sinon au mieux tu as des alertes ou erreurs.
Au pire ça retourne n'importe quoi.

[emixam16]

Bonjour,

Je ne suis pas sur de savoir quelle est ta question

- Soit tu ne comprend pas comment marche un return. Et là je te conseille de reprendre un tutoriel depuis la première page.
- Soit tu te poses la question un peu plus subtile suivante:

Mon code devrait ne pas marcher puisque ma fonction déclare retourner un int et il n'y a pas de return. Pourquoi mon code peut-il être exécuté?

Je vais répondre à la version intéressante en espérant que ce soit la bonne...

En fait, le C est un langage qui permet de faire beaucoup de choses, y compris "n'importe quoi". C'est dû à des raisons de design et surtout de performances.

Normalement, quand tu fais un return, ton programme va mettre une valeur de retour dans un registre, et cette valeur va être lue par la fonction appelante. Si la fonction ne retourne rien, alors ce registre contiendra la valeur qu'il y avait avant. Ca peut être 0, 42 , -3558468, ou n'importe quoi. On parle d'un comportement indéfini (undefined behavior) (UB). C'est très mauvais, à partir du moment ou tu as un UB, considère que ton programme peut faire n'importe quoi, et peut même donner des résultats différents entre deux exécutions. C'est d'ailleurs confirmé par la norme C

If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.

Bref, évite les UB, c'est un très bon moyen de perdre plein de temps à déboguer ton programme quand il deviendra complexe. Et ça n'amusera pas tes collègues.

Edit: grillé
Edit2: Arf, en relisant le message original, l'OP ne doit juste pas comprendre comment marchent les return... Et accessoirement les variables locales... Je laisse quand même mon message au cas ou il serve à un lecteur

[chris7522]

C'etait bien cette question que je me posais , a savoir : Mon code devrait ne pas marcher puisque ma fonction déclare retourner un int et il n'y a pas de return. Pourquoi mon code peut-il être exécuté?
J'aurai aimé avoir un message d'erreur a la compilation, de cette facon j'aurai compris qu'il faut systématiquement faire un return apres mes fonctions non void . Mais malheureusement ca passe quand meme !
Je vais suivre vos conseils et le faire sans manquements.
Merci de votre aide

[Bousk]

Parce que les compilos C peuvent être souples.
Plus ils sont vieux, plus ils le seront.
Faudrait au moins indiquer lequel tu utilises.
Il faut activer tous les warnings dans les options de compilation. -wall

[chris7522]

Il s'agit de gcc version 7.4.0 .
Je suis passé a la version version 8.3.0 . Et effectivement , apres avoir activé les warning , le manque de return sur mes fonctions est signalé !

[Bktero]

Seule la fonction main() autorise à ne pas avoir de return explicite. Et seulement depuis C99.

In case a return value is not defined by the programmer, an implicit return 0; at the end of the main() function is inserted by the compiler; this behavior is required by the C++ standard.

[chris7522]

Par contre j'ai fais ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#include <stdio.h>
#include <stdlib.h>
#define MAX 20
 
int nb_article(){
 int nb;
 do{
   printf("Nombre d'article voulu:\n");
   scanf("%d",&nb);
   }while(nb<5);
return nb;
}
 
 
void taille(int t,int tab[]){
 int i;
 for(i=0;i<t;i++){
  printf("Entrez une taille:");
  scanf("%d",&tab[i]);}
}
 
int main(){
 int tab[MAX];
 int nombre,i;
 
 nombre=nb_article();
 taille(nombre,tab);
 
 printf("Le nombre d'article choisi est de:%d\n",nombre);
 printf("Les tailles choisis sont:\n");
 for(i=0;i<nombre;i++)
  printf("%d\n",tab[i]);
  puts("\n");
 return 0;
}

Pour ma fonction taille , j'ai pas fais de retour et meme avec le Wall , tout va bien . Pourquoi ca passe ?
desolé pour mes questions pénible de débutant et merci de votre patience

[emixam16]

Pour le coup c'est tout à fait normal.

Ta fonction taille retourne void... C'est à dire vide, rien.

Donc c'est normal que tu ne retourne rien et que ton compilo ne s'en plaigne pas, c'est le comportement attendu!

Note de bas de page:
Tu aurais pu aussi utiliser return; pour quitter explicitement ta fonction. Sinon, ton flot d'exécution va jusqu'à la dernière parenthèse fermante. Je te met un exemple de cas où le return; peut être utile.

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
void f(int* arg) {
    if(!*arg) { // On vérifie que l'argument est valide
        perror("Nope.");
        return; // Littéralement: je retourne la valeur "rien du tout"
    }
    ++*arg; // On est sur qu'on est pas dans le cas d'erreur. On fait notre traitement.
}

Ici on aurait pu organiser le code pour se passer de l'early return, mais dans certains cas, cela peut rendre le code plus clair (par exemple en limitant le niveau d'indentation).

[sambia39]

Bonjour,

Je te met un exemple de cas où le return; peut être utile.

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void f(int* arg) {
    if(!*arg) { // On vérifie que l'argument est valide
        perror("Nope.");
        return; // Littéralement: je retourne la valeur "rien du tout"
    }
    ++*arg; // On est sur qu'on est pas dans le cas d'erreur. On fait notre traitement.
}

Attention a cette instruction (!*arg)qui générera une Segmentation fault parce que l'on ne teste pas si le pointeur est valide, mais plutôt si la valeur pointée est présente ou pas ; sauf qu'en faisant ça, on utilise potentiellement un pointeur qui n'est pas initialisé dont le résultat de l'exécution de cette instruction est catastrophique.

à bientôt

[chris7522]

Difficile de faire abstraction de ses années d'experience en programmation lorsqu'on s'adresse a un debutant , n'est ce pas ?😉😀. Mais ta reponse profitera au plus grand nombre et c'est ce qui compte .

[Sve@r]

Bonjour

Attention a cette instruction (!*arg)qui générera une Segmentation fault parce que l'on ne teste pas si le pointeur est valide, mais plutôt si la valeur pointée est présente ou pas ; sauf qu'en faisant ça, on utilise potentiellement un pointeur qui n'est pas initialisé dont le résultat de l'exécution de cette instruction est catastrophique.

Je ne suis pas d'accord. "arg" est effectivement un pointeur mais dans cet usage, le programmeur considère qu'il est valide car il provient de l'appelant. C'est un "à priori" tout à fait autorisé.

Si par exemple je veux écrire un swap entre deux int, j'écrirai naturellement...

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void swap(int *a, int *b) {
	int t;
	t=(*a);
	(*a)=(*b);
	(*b)=t;
}

...sans me préoccuper de la validité de "a" et de "b" car je suppose que l'appelant fera les choses correctement. Et ça reste conforme à la philosophie du C du "le programmeur (appelant) sait ce qu'il fait (quand il appelle mon swap)".

Tu as le droit évidemment de rajouter ta propre protection if (arg == NULL) return; si tu envisages cette possibilité dans une utilisation normale de ta fonction mais cela n'est pas une obligation ; d'autant plus que ça ne vérifie même pas la validité du pointeur (chose qui reste de toute façon impossible à vérifier) mais seulement de sa "non nullité" (ce qui n'est pas la même chose).

[chris7522]

Merci a tous de votre aide

[sambia39]

Je ne suis pas d'accord. "arg" est effectivement un pointeur mais dans cet usage, le programmeur considère qu'il est valide car il provient de l'appelant. C'est un "à priori" tout à fait autorisé.

Si par exemple je veux écrire un swap entre deux int, j'écrirai naturellement...
...sans me préoccuper de la validité de "a" et de "b" car je suppose que l'appelant fera les choses correctement. Et ça reste conforme à la philosophie du C du "le programmeur (appelant) sait ce qu'il fait (quand il appelle mon swap)".

Tu as le droit évidemment de rajouter ta propre protection if (arg == NULL) return; si tu envisages cette possibilité dans une utilisation normale de ta fonction mais cela n'est pas une obligation ; d'autant plus que ça ne vérifie même pas la validité du pointeur (chose qui reste de toute façon impossible à vérifier) mais seulement de sa "non nullité" (ce qui n'est pas la même chose).

Non, on ne peut pas considérer (ou systématiquement considérer) qu'arg est valide parce qu'il provient de l'appelant, il est clairement défini dans le cas actuel comme étant le paramètre de la fonction "f" et non l'argument qui est passé à la fonction "f" (même si l'argument "xinconnue" est référencé par le paramètre arg) et comme tu l'as si bien souligné avec ton exemple de swap, on peut parfaitement ne pas se soucier de la validité ou non-nullité de arg, a condition/ parce que toutes précautions ou éventuels traitements sur l'argument "xinconnue" ont été prises avant l'appel à la fonction "f".

Que ça soit dans une utilisation normale ou pas et que l'on effectue un test de validité des pointeurs, c'est pour s'assurer que le ou les pointeurs que l'on va manipuler n'ont été correctement initialisés d'une part et de l'autre que l'appellant qui fournit l'argument à la fonction n'a pas forcement pris des précautions et dans ce cas, on ne peut pas effectué un test de validité en accédant directement à l'objet pointé. Il vaut mieux comme tu le précaunises effectuer un if(NULL == arg) et ensuite accéder à la valeur pointée et donc, attention à l'instruction !*arg (avec le commentaire qui lui est associé) qui est potentiellement un pointeur non initialisé d'une part et de l'autre parce que l'on n'a également aucune idée ou exemple de l'argument qui lui est transmis ou ce qui justifie l'instruction en question et n'oublions pas qu' un programme fait exactement ce qui est écris et pas le contraire.

[Sve@r]

Ok j'ai compris
Ce qui te gêne, ce n'est pas qu'on utilise *arg sans avoir vérifié arg (ce que je fais avec mon swap qui utilise *a et *b sans avoir vérifié a ou b) mais qu'on écrive if(!*arg) { // On vérifie que l'argument est valide c'est à dire qu'on regarde le pointé pour vérifier le pointeur.
Ok, je suis d'accord. Pour vérifier un pointeur, on regarde effectivement le pointeur parce que regarder le pointé ça ne sert à rien et pire ça provoque un UB

[emixam16]

Mea culpa. Je voulais présenter un code "trivial" donc faire une seule vérification. Je l'ai choisie en faisant appel à mon pifomètre (que l'entier soit non nul). Mais quitte à faire une seule vérification autant vérifier le pointeur, comme ça été dit plus haut. Merci pour votre œil attentif

(Malgré tout, ce code vise juste à montrer l'intérêt early return, il est presque à voir comme du pseudo-code)

[Médinoc]

Le problème de ça, c'est que tu n'as pas donné de raison pour laquelle on voudrait que la fonction refuse d'incrémenter un entier qui commence nul (alors qu'il est trivial d'expliquer pourquoi on ne veut pas d'un pointeur nul ici).