Ouverture d'un fichier par une fonction.

Salut!:D

Supposons que l'on veuille déléguer à une fonction la tâche d'ouverture d'un fichier avec toutes les vérifications qui vont avec:

Code:

---

1 2 3 4 5 6

FILE* f(char* path){ ... FILE* file=fopen(path,"r"); ... return file; };

---

1)Est-ce "file" se comportera comme n'importe quelle variable locale et donc le renvoyer impliquera un comportement indéterminé?
2)De plus est-ce qu'un fichier ouvert dans une fonction le restera à la sortie de la fonction?

Si la réponse à 1) est oui alors est-ce que:

Code:

---

1 2 3 4

FILE** file=malloc(sizeof(*file)); *file=fopen(path,"r"); ... return file;

---

est correct et est-ce que le fichier restera toujours ouvert en dehors de la fonction?

Merci de vos réponses.:D

alors,
1°) non car il s'agit d'un pointeur (retour par valeur, pas de problème)
2°) oui
3°) sert à rien + alloc dynamique => mauvaise idée ;)

Citation:

---

non car il s'agit d'un pointeur (retour par valeur, pas de problème)

---

Euh, ce n'est pas une question de pointeur:

Code:

---

1 2 3 4 5

void f(){ int a=0; int* p=&a; return p; }

---

car à la sortie de la fonction "p" pointera sur une zone mémoire non valide: là ou se trouvait "a" donc comportement indéfini.

Donc ici le fait que ce soit un pointeur sur un fichier et que le fichier reste ouvert implique que c'est valide.

si, parce que là, tu as un pointeur de variable local, c'est un autre problème ;)

alors que fopen renvoie un pointeur de ressource... [c'est vrai que j'ai oublié de parler de ce point là]

Citation:

---

Envoyé par seriousme

Euh, ce n'est pas une question de pointeur:

Code:

---

1 2 3 4 5

void f(){ int a=0; int* p=&a; return p; }

---

car à la sortie de la fonction "p" pointera sur une zone mémoire non valide: là ou se trouvait "a" donc comportement indéfini.

Donc ici le fait que ce soit un pointeur sur un fichier et que le fichier reste ouvert implique que c'est valide.

---

Oui mais là le FILE * est déjà un retour de fonction donc c'est forcement possible.

Citation:

---

alors que fopen renvoie un pointeur de ressource...

---

C'est ce que j'ai écrit:

Citation:

---

un pointeur sur un fichier et que le fichier reste ouvert

---

Par contre je ne connaissais pas ce terme "pointeur de ressource".

Citation:

---

renvoie un pointeur de ressource

---

Pas vraiment, un pointeur est une variable donc il est détruit à la sortie de la fonction.
C'est son contenu, l'adresse de la ressource, qui est renvoyé et est valide.

Citation:

---

déjà un retour de fonction donc c'est forcement possible.

---

C'est bien vu.:mrgreen:

Citation:

---

Envoyé par seriousme

Par contre je ne connaissais pas ce terme "pointeur de ressource".

---

C'est un pointeur sur n'importe quoi pouvant remplir les conditions citées dans la norme :

Citation:

---

FILE
which is an object type capable of recording all the information needed to control a
stream, including its file position indicator, a pointer to its associated buffer (if any), an
error indicator that records whether a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has been reached; and

---

Donc le plus simple étant une structure mais tu peux t'amuser à linéariser tout ça dans un int alloué avec malloc (pour pouvoir le retourner).

Citation:

---

Envoyé par seriousme

Code:

---

1 2 3 4 5 6

FILE* f(char* path){ ... FILE* file=fopen(path,"r"); ... return file; };

---

1)Est-ce "file" se comportera comme n'importe quelle variable locale et donc le renvoyer impliquera un comportement indéterminé?

---

M'enfin, tu sors ça d'où ? Personne n'a jamais prétendu cela. Ce qui est interdit c'est de retourner l'adresse d'une variable locale, pas son contenu.

Citation:

---

pas son contenu

---

Justement c'est bien le problème:
le contenu est l'adresse d'un fichier.
Mais comme le fichier reste ouvert à la sortie de la fonction le contenu est valide.
C'est sur ce dernier point que j'avais un doute.

Citation:

---

Ce qui est interdit c'est de retourner l'adresse d'une variable locale, pas son contenu.

---

Tout dépend du contenu:

Code:

---

1 2 3 4 5

void f(){ int a=0; int* p=&a; return p; }

---

Mais là, le contenu est l'adresse d'une variable locale, donc ça rentre dans le cadre de l'interdiction.

Je suis d'accord, mais "p" est une variable locale et son contenu est invalide.
C'est juste pour faire remarquer que dire:

Citation:

---

Ce qui est interdit c'est de retourner l'adresse d'une variable locale, d'une manière ou d'une autre.

---

est plus explicite que:

Code:

---

Ce qui est interdit c'est de retourner l'adresse d'une variable locale, pas son contenu.

---

L'exemple donné appliquant mot pour mot cette phrase.

seriousme

Citation:

---

Citation:
Ce qui est interdit c'est de retourner l'adresse d'une variable locale, pas son contenu.

Tout dépend du contenu:

Code:

---

1 2 3 4 5 6

void f(){ int a=0; int* p=&a; return p; }

---

---

Emmanuel a (comme toujours et c'est énervant:aie: ) raison, ce code est pervers parce qu'il retourne l'adresse d'une variable locale !

Pour résumer :
1- On retourne TOUJOURS une valeur
2- Cette valeur ne doit pas être l'adresse d'une variable locale
Variante de l'exemple de seriousme

Code:

---

1 2 3 4 5

int *f() { int a=0; return &a; }

---

Citation:

---

Envoyé par seriousme

le contenu est l'adresse d'un fichier.

---

L'adresse d'un fichier ? Non. L'adresse d'un objet de type FILE créé par fopen(). Cet objet existe tant qu'on appelle pas fclose(). Je ne comprend pas bien tes interrogations... C'est comme malloc()/free() ou n'importe quel autre ADT comme il y en plein GTK+, SDL ou ma CLIB...

Par contre, il ne faut pas retourné un pointeur alloué par alloca() (qui alloue sur la pile).

Une chose regrettable à propos de FILE est que ce n'est pas un type de données complètement abstrait, puisque son contenu est visible (à cause des macros).

Citation:

---

L'adresse d'un fichier ? Non. L'adresse d'un objet de type FILE créé par fopen().

---

Oui une structure FILE.
C'est moi qui traduit bêtement le nom de cette structure.:mrgreen:

Citation:

---

Envoyé par Médinoc

Une chose regrettable à propos de FILE est que ce n'est pas un type de données complètement abstrait, puisque son contenu est visible (à cause des macros).

---

Quelle macro ?

Citation:

---

Envoyé par gege2061

Quelle macro ?

---

Certaines 'methodes' de FILE sont parfois implémentées sous forme de macros (fgetc(), feof() etc.). Mais je rappelle

1. Que le C exige qu'une version 'fonction' existe :
   
   Code:

   ---

   1 2 3 4 5

   #include <stdio.h>   { int x = (fgetc)(stdin);

   ---

2. Que le C n'exige pas de version macro.

La version totalement abstraite de FILE est donc tout à fait envisageable.