malloc de structure - C - Programmation
Marsh Posté le 27-01-2016 à 21:23:04
antiseptiqueincolore a écrit : Bonjour,
|
Malloc ne mets pas la mémoire à 0. Calloc si.
Pour le reste sans code impossible de t'aider.
Marsh Posté le 28-01-2016 à 17:14:18
antiseptiqueincolore a écrit : Bonjour,
|
Sous OSX avec Clang 7.0.2, j'ai du garbage depuis le malloc et une mémoire à 0 via calloc
Code :
|
toto: |
[0] les bsd ont malloc.conf qui permet de configurer ça
Marsh Posté le 28-01-2016 à 20:07:40
on arrive au point que je ne comprends pas. Il me manque une bille pour comprendre.
Dans le cas d'un calloc, mon déreférencement de pointeur il plante aussi.
La zone mémoire vaut zéro on est d'accord. mais le pointeur c'est quoi son état????
avec calloc, si je fais un if(values) je passe quand même dedans.
Pour que mon code ne plante pas, il a fallu que je fasse un calloc, admettons, et que je set le pointeur à NULL par la suite pour pas que ça plante.
C'est ça que je ne comprends pas
et merci aussi
Marsh Posté le 28-01-2016 à 20:24:04
antiseptiqueincolore a écrit : |
C'est un pointeur vers l'adresse 0?
antiseptiqueincolore a écrit : avec calloc, si je fais un if(values) je passe quand même dedans. |
if(values)? de quoi tu parles? Ya pas de locale values dans le peu de code que t'as donné, ça sort d'où?
antiseptiqueincolore a écrit : C'est ça que je ne comprends pas |
Que tu comprends pas quoi?
Marsh Posté le 28-01-2016 à 20:31:36
je crois que c'est la notion de NULL qui me manque. Je vais aller lire.
donc on a :
Code :
|
et je me fais un truc après du style if (toto[0].values) blabla. Et c'est là que je suis étonné de passer dedans.
Je m'attendais à ce que des double soient mis à zéro et les pointeurs à null.
et donc c'est pas le cas.
Marsh Posté le 28-01-2016 à 22:46:08
antiseptiqueincolore a écrit : je crois que c'est la notion de NULL qui me manque. Je vais aller lire. donc on a :
|
1. comme il te l'a été dit, un malloc ne fait pas d'initialisation il réserve juste l'espace, tu récupères le bordel qui est déjà en mémoire et ça peut être tout et n'importe quoi, tu ne dois surtout pas utiliser la mémoire allouer sans l'initialiser
2. un pointeur null n'est pas nécessairement représenté par une mémoire à 0, c'est un détail d'architecture, bzero ou memset(0) sur le pointeur même, ça ne donne pas un pointeur null de manière portable
Marsh Posté le 28-01-2016 à 23:38:40
masklinn a écrit : 2. un pointeur null n'est pas nécessairement représenté par une mémoire à 0, c'est un détail d'architecture |
Tu as un exemple concret d'architecture en tête? Je suis un peu étonné car on voit (ou en tout cas je vois) souvent des trucs genre
Code :
|
je vois mal comment ça peut fonctionner si le pointeur NULL (que retourne malloc() en cas d'erreur, j'ai vérifié c'est bien NULL et non 0) est différent de 0. C'est un cas spécial que prends en compte le compilateur? Ou c'est moi qui n'a pas compris le problème? Ou mon exemple est-il faux et il faudrait utiliser un test ==NULL?
J'ai regardé dans le K&R, il n'y a qu'une mention de NULL, pas grand chose d'intéressant. Ce qui, au passage, est curieux c'est que d'après le même bouquin NULL est défini dans stdio.h, pourtant dans mon MinGW je trouve du #define NULL uniquement dans windef.h.
Ah le C est ses subtilités...
Marsh Posté le 29-01-2016 à 09:01:58
rat de combat a écrit : Tu as un exemple concret d'architecture en tête? |
http://c-faq.com/null/machexamp.html
rat de combat a écrit : Je suis un peu étonné car on voit (ou en tout cas je vois) souvent des trucs genre
|
L'exemple est correct, la spec C définit `if (!foo)` comme équivalent à `if (foo == 0)`. Si "foo" est un pointeur, le second membre est un "integral constant expression with the value 0" (un 0 constant litéral dans un contexte de pointeur), qui est spécifié comme générant un pointeur null. Notes que la partie "constante" est importante, c'est une conversion faite par le compilateur, un entier de valeur 0 converti pendant l'exécution (avec un cast) c'est un pointeur vers l'adresse 0, qui n'est pas nécessairement invalide (et notes que déréférencer un NP c'est une UB, c'est pas nécessairement un crash)
Marsh Posté le 30-01-2016 à 17:41:40
Ouais... Je retiens simplement que mon exemple (if(!ptr) ou if(ptr==0)) est correct peu importe comment un pointeur null est représenté. Est-ce exact? (Et pour la UB, que ce soit ça ou un crash les deux ne sont pas bons...). Merci pour la réponse en tout cas.
Marsh Posté le 30-01-2016 à 18:21:21
rat de combat a écrit : Ouais... Je retiens simplement que mon exemple (if(!ptr) ou if(ptr==0)) est correct peu importe comment un pointeur null est représenté. Est-ce exact? |
Oui.
Marsh Posté le 31-01-2016 à 11:36:21
Certes, mais tant qu'à écrire un truc comme if (ptr == 0) autant écrire if (ptr == NULL).
La raison pour laquelle l'idiome C if (!ptr) est couramment utilisé, c'est pour éviter de faire la faute de frappe if (ptr = 0).
A+,
Marsh Posté le 27-01-2016 à 20:35:24
Bonjour,
ça fait longtemps que je n'ai pas fait de c, et je dois en refaire un peu.
Je vais taper le code de tête, ça n'est pas supposé compiler
ma question est: est-ce que les values dans chaque dict sont supposées être dans un état précis? En debug sous vs2008 les pointeurs n'ont pas l'air d'etre nuls avec calloc non plus.
merci, c'est pour la science
edit : en fait c'est plus que ça. Le pointeur n'a pas l'air nul, mais en plus, quand j'essaie de savoir s'il est nul, ça plante
Message édité par antiseptiqueincolore le 27-01-2016 à 21:10:31