Discussion :

[dj.motte]

Bonjour,

Soit un pointeur sur donnée:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
typedef struct A
{ int i ;
  char [10] z; 
} A ;
 
A * a = (A*) malloc( sizeof(A) ) ;
free( a ) ;
a = 0 ;
// ou a = NULL;

Y-a-t-il une différence entre NULL et zéro ? Dans un environnement 32 bits, bien entendu.

Salut.

[Thierry Chappuis]

La norme du langage C n'assure pas que NULL vaudra zéro (mais là, il faut que je vérifie, et j'ai pas le courage de me plonger dans la norme maintenant). NULL doit correspondre à une adresse invalide. Toutefois, sur la plupart des implantations que je connaisse, NULL est défini comme (void *) 0. Il s'agit donc d'un pointeur alors que 0 est une valeur de type int.

Pour des questions de portabilité, initialiser un pointeur à NULL est une manière de dire: "cette adresse ne pointe pas sur une zone valide". En plus, NULL a l'avantage d'être une valeur testable, et permet ainsi d'examiner la validité de la valeur contenue par un pointeur.

En résumé: si tu veux écrire du code portable, il est recommandé de ne faire aucune supposition quand à la valeur de NULL.

En ce qui concerne ton morceau de code ci-dessus, il est générallement recommandé de ne pas caster la valeur de retour de malloc(). Par ailleurs, il y a une erreur de syntaxe dans la déclaration du tableau z, et la valeur de retour de malloc n'est pas testée...

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
#include <stdio.h>
#include <stdlib.h>
 
typedef struct A_
{
    int i ;
    char z[10];
} A_s;
 
int main(void)
{
    /* Le cast de malloc() est déconseillé */
    A_s *a = malloc(sizeof *a);
    /* TOUJOURS vérifier la valeur de retour de malloc */
    if (a != NULL)
    {
        /* Des traitements faisant appel à a */
 
        free((void *) a), a = NULL;
    }
    else
    {
        fprintf(stderr, "L'allocation a échoué!\n");
        exit(EXIT_FAILURE);
    }
 
    return EXIT_SUCCESS;
}

Thierry

[Emmanuel Delahaye]

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
<...>
   if (a != NULL)
    {
        /* Des traitements faisant appel à a */
 
        free((void *) a), a = NULL;
    }
    else
    {
        fprintf(stderr, "L'allocation a échoué!\n");
        exit(EXIT_FAILURE);
    }
 
    return EXIT_SUCCESS;
}

Pourquoi rompre l'harmonie de la programmation structurée ? Tu ne te rends pas compte des conséquences cosmologiques que ça entraine... Moi, ça m'empêche de dormir en tout cas...

Et pourquoi un cast pour free () ? Il n'est pas plus utile que celui du retour de malloc()...

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
 
#include <stdio.h>
#include <stdlib.h>
 
typedef struct
{
    int i ;
    char z[10];
} 
A_s;
 
int main (void)
{
   int ret = EXIT_SUCCESS;
   A_s *a = malloc (sizeof *a);
 
   if (a != NULL)
   {
      /* Des traitements faisant appel à a */
 
      free (a), a = NULL;
   }
   else
   {
      fprintf(stderr, "L'allocation a échoue!\n");
      ret = EXIT_FAILURE;
   }
 
   return ret; 
}

[Thierry Chappuis]

Pourquoi rompre l'harmonie de la programmation structurée ? Tu ne te rends pas compte des conséquences cosmologiques que ça entraine... Moi, ça m'empêche de dormir en tout cas...

Parce que je n'ai pas réfléchi plus loin, et que c'est devenu chez moi une suite d'instruction idiomatique (c'est vrai que ça m'empêche de dormir, maintenant qu'on en parle...). Je vais corriger ma manière de faire.

Et pourquoi un cast pour free () ? Il n'est pas plus utile que celui du retour de malloc()...

Je ne sais plus pourquoi j'ai commencé à caster les paramètres que je passe à free(). Je crois que c'était sur conseil de mon compilateur. Bref, je n'y tiens pas plus que tant... Par contre, s'il n'est pas plus utile que le cast d'un retour de malloc(), il est moins dangereux. En effet, en cas d'oubli de l'inclusion de stdlib.h, caster le retour de malloc élimine la possibilité pour le compilateur de rapporter cet oubli, tandis que caster ou pas l'argument passé à free() ne change simplement rien. Au pire c'est inutile. Je vais suivre ton conseil et cacher ce cast que je ne saurais voir...

Merci pour tout

Thierry (qui progresse vite, mais à qui il faut expliquer longtemps)

[dj.motte]

Bonjour,

Mujigka écrit :

En ce qui concerne ton morceau de code ci-dessus, il est générallement recommandé de ne pas caster la valeur de retour de malloc(). Par ailleurs, il y a une erreur de syntaxe dans la déclaration du tableau z, la valeur de retour de malloc n'est pas testée

C' était tout simplement un exemple court , pas la peine de vérifier.

A mon avis, une bibliothèque écrite en C, avec la convention du 0 à la place du NULL, pourrait fonctionner en C++, sauf si ...

Salut.

[Thierry Chappuis]

C' était tout simplement un exemple court , pas la peine de vérifier.

Mais, c'est dans les exemples courts que se profilent déjà les bonnes habitudes

A mon avis, une bibliothèque écrite en C, avec la convention du 0 à la place du NULL, pourrait fonctionner en C++, sauf si ...

Avec NULL, ça fonctionne aussi, car NULL est défini comme 0 (et non (void *)0) sur la plupart des implantations C++ que je connaisse. Ne pas caster malloc() peut entrainer des problèmes en compilant le code à l'aide d'un compilateur C++. De toute manière, je suis partisan de compiler du code C avec un compilateur C, et de prévoir un fichier d'en-tête auto-démerdant permettant au fichier objet en question d'être lié à un projet C comme à un projet C++. Exemple de fichier d'en-tête adapté pour lier une bibliothèque écrite en C à un programme écrit en C++:

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
#ifndef H_TC_MONHEADER_20070218003822
#define H_TC_MONHEADER_20070218003822
 
#ifdef __cplusplus
extern "C" {
#endif
 
void fonction1(void);
int fonction2(int, int);
 
#ifdef __cplusplus
}
#endif
 
#endif /* guard H_TC_MONHEADER_20070218003822 */

Thierry

[Jean-Marc.Bourguet]

Avec NULL, ça fonctionne aussi, car NULL est défini comme 0 (et non (void *)0) sur la plupart des implantations C++ que je connaisse.

NULL doit être une constante entière en C++. (void*)0 est interdit (et ne fonctionnerait pas parce qu'il n'y a pas de conversion implicite de void* vers les autres types de pointeurs).

[Jean-Marc.Bourguet]

Petit ajout, ne pas oublier que NULL doit être casté en un pointeur quand il sert d'argument à une fonction variadique ou à une fonction sans prototype. Les implémentations qui définissent NULL comme (void*) le font pour éviter de casser le code qui l'oublie, mais toutes ne sont pas dans ce cas.

[Emmanuel Delahaye]

Soit un pointeur sur donnée:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
typedef struct A
{ int i ;
  char [10] z; 
} A ;
 
A * a = (A*) malloc( sizeof(A) ) ;
free( a ) ;
a = 0 ;
// ou a = NULL;

Y-a-t-il une différence entre NULL et zéro ?

Ici, non. Mais NULL a valeur documentaire dans un contexte pointeur, et il est préférable de l'utiliser dans ce cas là.

On a pas le droit de l'utiliser ailleurs que dans un contexte pointeur. Par exemple :

Code :

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

int i = NULL;

est faux (comportement indéfini)

Rappel : Dans le code C que tu as posté, le cast est inutile.

Dans un environnement 32 bits, bien entendu.

"Irrelevent Captain !"
--Spock in TOS

[Thierry Chappuis]

An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.55) If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.

et

NULL
which expands to an implementation-defined null pointer constant;

Oui, la norme assure que NULL sera remplacé par la valeur 0 ou (void *) 0.

Thierry

[Jean-Marc.Bourguet]

et


Oui, la norme assure que NULL sera remplacé par la valeur 0 ou (void *) 0.

Thierry

Ou 0L, (void*)0L, (42-21-21),... en pratique j'ai déjà vu le premier cas.