Discussion :

[souviron34]

D'ailleurs, il n'est même pas garanti qu'un pointeur nul, qui vu du C vaut zéro, soit bien représenté par "all bits to zero" en mémoire.
Edit: Ni même un entier (un bète int), je pense...

Bref, ce n'est pas portable.

Ben 0x0 ça donne pas des zéros partout ??? je sais pas , j'ai jamais compté ni en hexa, ni en octal, mais il me semblait bien.. `

Et de toutes façons je ne vois pas en quoi ça a un rapport avec "ça n'est pas portable".. calloc fait partie du langage standard... Pour une utilisation "à priori" oui.

Je préfère de toutes façons utiliser calloc que malloc, toujours, car comme on l'a dit plus haut, on se sait pas ce qui traîne, donc ça pourrait être par exemple une instruction , un chiffre qui viendra mettre la pagaille dans le tableau, etc.... Donc je préfère savoir qu'il y a des zéros partout....

[EDIT]

et d'ailleurs, c'est entier, ce qu'il met, car en fait ça utilise memset, et memset pour que ce soit à 0 tu lui passes 0L ....

[/EDIT]

[koala01]

Pour ce qui est de calloc, il initialise, selon opengroup tout l'espace à 0...ce qui, comme l'a si bien fait remarquer médinoc, ne correspond pas *forcément* à NULL, selon les implémentations/le matériel...

La difficulté de compréhension venant surement du fait que null, en anglais, c'est 0... mais ici, on est dans le cadre d'une définition de valeur (un simple #define) qui peut tres bien changer

[souviron34]

Pour ce qui est de calloc, il initialise, selon opengroup tout l'espace à 0...ce qui, comme l'a si bien fait remarquer médinoc, ne correspond pas *forcément* à NULL, selon les implémentations/le matériel...

La difficulté de compréhension venant surement du fait que null, en anglais, c'est 0... mais ici, on est dans le cadre d'une définition de valeur (un simple #define) qui peut tres bien changer

je disais juste que je préfère avoir un tableau intialisé à une valeur connue que d'avoir n'importe quoi, y compris possiblement une mauvaise instruction ou un chiffre abherrant...

[Médinoc]

La difficulté de compréhension venant surement du fait que null, en anglais, c'est 0... mais ici, on est dans le cadre d'une définition de valeur (un simple #define) qui peut tres bien changer

Il n'est même pas ici question du define.

La norme C garanti que vu du C, le pointeur NULL sera égal à zéro.
Le problème, c'est que memset() et calloc() ne connaissent pas le type, donc bypassent complètement l'aspect "vu du C" en mettant une succession de bits ou d'autre chose à zéro, sans garantir du tout que cela corresponde vraiment à zéro pour le type concerné...

[koala01]

Il n'est même pas ici question du define.

La norme C garanti que vu du C, le pointeur NULL sera égal à zéro.
Le problème, c'est que memset() et calloc() ne connaissent pas le type, donc bypassent complètement l'aspect "vu du C" en mettant une succession de bits ou d'autre chose à zéro, sans garantir du tout que cela corresponde vraiment à zéro pour le type concerné...

Ce que je voulais surtout faire remarquer c'est qu'il faut etre prudent dans les termes utilisés

une valeur nulle

ne peut *pas forcément* etre concidérée comme identique à

NULL

simplement parce que NULL peut etre redéfini à volonté (ou presque)... et que, bien qu'il puisse sembler que les deux termes soient identiques, il n'en reste pas moins que ca revient presque à comparer une pomme avec une poire

[Emmanuel Delahaye]

Est il possible de savoir de quel taille a été une allocation en ayant juste l'adresse premiere case

Non. C'est à toi de prendre des notes. Je recommande ceci :

Code :

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

1
2
3
4
5
6
 
struct tab_T
{
   size_t nb_elem;
  T* array;
};

car je n'ai pas saisi si pour toutes les chaines la terminaison était toujours '\0'?

Une chaine valide est toujours terminée par un 0, mais ça ne donne aucune indication sur la taille réelle du tableau

[sone47]

on passe une structure avec le nombre d'elements et l'adresse, mais je ne comprend l'annotation que vous avez utilisé

Code :

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

T* array;

Et pour les pointeurs de pointeurs plus haut cela correspond il?

[Emmanuel Delahaye]

Le point 3 est justement très pratique pour les chaînes et les structures, puisqu'il initialise tout à NULL (je crois). Donc aucun danger (sauf si on dépasse la taille allouée bien entendu) d'oublier un '\0', et si on fait des copies par opération de pointeur, on est cependant certain que ce sera terminé par un '\0'..
.

Euh, non. Il initialise à 'all-bits-to-zero', ce qui ne signifie pas forcément 0, 0.0 ni NULL... Ca dépend de l'implémentation. C'est donc une fausse bonne idée (même si, dans la pratique, on voit rarement de différence).

[Emmanuel Delahaye]

Ben 0x0 ça donne pas des zéros partout ???

Ce n'est pas garanti. En C99, il existe la notion de 'trap representation' pour les entiers autres que char. Rien ne dit que 'all-bit-to-zero' n'en soit pas une.

Et de toutes façons je ne vois pas en quoi ça a un rapport avec "ça n'est pas portable".. calloc fait partie du langage standard... Pour une utilisation "à priori" oui.

En C90, son utilisation n'est portable que pour des entiers. En C99, uniquement pour des des [[un]signed ]char.

Je préfère de toutes façons utiliser calloc que malloc, toujours, car comme on l'a dit plus haut, on se sait pas ce qui traîne, donc ça pourrait être par exemple une instruction , un chiffre qui viendra mettre la pagaille dans le tableau, etc.... Donc je préfère savoir qu'il y a des zéros partout....

Mais il y a une différence entre mettre des 0 partout ce qui est correct et souhaitable et mettre tous les bits à 0, ce qui produit un effet non portable.

Je recommande ceci qui est portable :

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
 
   T *p = malloc (sizeof *T * N);
 
   if (p != NULL)
   {
      size_t i;
 
      for (i = 0; i < N; i++)
      {
         static const T z = {0};
         p[i] = z;    
      }
 
      /* etc. */
   }

et d'ailleurs, c'est entier, ce qu'il met, car en fait ça utilise memset, et memset pour que ce soit à 0 tu lui passes 0L ....

On passe un entier a memset(), dont les bits de poids faibles (unsigned char) sont recopiée tels quels dans les bytes de la zone mémoire considérée. Il n'y a pas de notion de 'valeur' , mais une simple recopie d'un pattern de bits.

[Emmanuel Delahaye]

je disais juste que je préfère avoir un tableau intialisé à une valeur connue que d'avoir n'importe quoi, y compris possiblement une mauvaise instruction ou un chiffre abherrant...

Sauf si cette combinaison de bits provoque un trap à la premier lecture de la variable concernée... Il vaut soit se renseigner sur l'implémentation courante, soit utiliser une initialisation portable.

[souviron34]

eh bien ça veut donc dire que je programme de manière très sûre alors, si c'est aussi dangereux que ça... vu que je n'ai aucun bug de mémoire dans ma très grosse application, et qu'il y a plus de milles calloc et realloc....

[koala01]

Il faut croire ...

Tu sais, il est des gens qui n'utilisent que scanf, et qui pourtant, comme ils l'utilisent correctement, fournissent des programmes tres stables et sécurisants

Je suis intimement persuadé que ce qui fait la stabilité d'une application tiens finalement en peu de mots:

• concetption et algorithmie correctes,
• utilisation en conscience des fonctions appropriées

Si tu travailles en gardant ces deux grandes lignes en tete, il est déjà fort vraissemblable que tu codes de manière très sure

[Emmanuel Delahaye]

eh bien ça veut donc dire que je programme de manière très sûre alors, si c'est aussi dangereux que ça... vu que je n'ai aucun bug de mémoire dans ma très grosse application, et qu'il y a plus de milles calloc et realloc....

Tu as une drôle de façon de raisonner...

Un programme peut avoir un comportement parfaitement défini et stable sur une plateforme, mais, parce qu'il n'est pas écrit de façon portable, avoir un comportement indéfini sur une autre. Ca n'a rien à voir avec "je programme de manière très sûre".

Si la portabilité n'entre pas en compte, c'est OK. Sinon, le comportement est indéfini. C'est tout.

Ce qui fait que le codage est 'de qualitaÿ', c'est la maitrise absolue des comportements indéfinis. Il ne doit pas y en avoir. Pour ça, il faut très bien connaitre le C de l'intérieur (la norme), c'est pour ça que je dis souvent que le C n'est pas un langage de débutant. C'est plutôt un langage pour professionnels avertis.

"C is a sharp tool"

Et il faut cesser de croire que le comportement visible suffit pour qualifier un code.

Ada est beaucoup plus clair pour ça. Il a été conçu de A à Z pour justement éviter les comportements indéfini.

[souviron34]

En C90, son utilisation n'est portable que pour des entiers. En C99, uniquement pour des des [[un]signed ]char.

Je ne vois pas trop où tu as vu ça...

C99 :

http://www.open-std.org/JTC1/SC22/WG...docs/n1124.pdf

7.20.3.1 The calloc function
Synopsis
1 #include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
Description
2 The calloc function allocates space for an array of nmemb objects, each of whose size is size. The space is initialized to all bits zero.
3 The calloc function returns either a null pointer or a pointer to the allocated space

C89 : (K&R)

void *calloc(size_t n, size_t size)
returns a pointer to enough free space for an array of n objects of the specified size, or NULL if the request cannot be satisfied. The storage is initialized to zero.
The pointer returned by malloc or calloc has the proper alignment for the object in question, but it must be cast into the appropriate type, as in
int *ip;
ip = (int *) calloc(n, sizeof(int));

[Médinoc]

Il a vu ça ici:

The space is initialized to all bits zero.

[souviron34]

Il a vu ça ici:

Non je parlais que c'est portable pour les entiers en 90 (et les char en 99)...

[Médinoc]

Cette histoire de portabiblité ou non est liée à ça.
Il doit donc y avoir quelque chose dans la norme qui indique si un entier est ou non compatible avec "all-bits-to-zero", mais certainement pas dans la spec de calloc()...

[souviron34]

ben de toutes façons je mentionnais simplement que j'utilisais systématiquement calloc plutôt que malloc pour avoir quelque chose d'initialisé et non pas du "garbage", mais en aucun cas je ne m'en sers... C'est juste une sécurité d'esprit...

[Emmanuel Delahaye]

Non je parlais que c'est portable pour les entiers en 90 (et les char en 99)...

Dans N1124, cherche 'trap representation'

Attention, la norme, c'est pas un mode d'emploi et encore moins un livre de cours, c'est une référence. Il faut savoir ce qu'on cherche.

[souviron34]

j'ai cherché et je ne vois pas en quoi ça altère mon raisonnement :

Si on se sert de calloc uniquement pour SAVOIR que la plage mémoire est initialisée, sans aller atteindre une valeur avant de l'avoir assignée, je ne vois pas le "danger"...

Quant à ce que tu marques ici :

static const T z = {0};
p[i] = z;

ça n'est pas vraiment plus sûr, puisque l'assignation n'assigne pas les bits de padding, et qu'ils sont indéfinis (d'après cette norme).

En fait j'utilises calloc uniquement pour économiser une ligne de memset..

Mais je ne me sers JAMAIS du fait que que c'est initialisé. Comme je disais plus haut, c'est uniquement une tranquillité d'esprit du fait de savoir qu'il n'y a pas n'importe quoi, mais que je sais ce qu'il y a ...