bonsoir,
tout est écrit dans le titresi j'initialise un poiteur sur NULL, il pointe où réellement sur la mémoire?
merci..
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pointeur Null pointe où ?
bonsoir,
tout est écrit dans le titre
merci..
Il n'y a pas de réponse portable à cette question à part 'nulle part'. Un pointeur valant NULL ne peut pas être déréférencé sous peine d'invoquer un comportement indéfini.Envoyé par Blue_Strike
tout est écrit dans le titre
Personnellement, je considère l'initialisation d'un pointeur à NULL comme une manière de dire "la valeur contenue dans ce pointeur ne correspond pas à une adresse valable". Par conséquent, ce pointeur de doit pas être déférencé avant de recevoir une adresse valide.
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
bonsoir,
mais si tu choisi la réponse 'nulle part' c'est comme tu as affecté la valeure 'vide' à une variable booléenne qui ne supporte que 0 ou 1 (vrai ou faux)Emmanuel Delahaye a écrit :
Il n'y a pas de réponse portable à cette question à part 'nulle part'. Un pointeur valant NULL ne peut pas être déréférencé sous peine d'invoquer un comportement indéfini.
oui et non !mujigka a écrit :
Personnellement, je considère l'initialisation d'un pointeur à NULL comme une manière de dire "la valeur contenue dans ce pointeur ne correspond pas à une adresse valable". Par conséquent, ce pointeur de doit pas être déférencé avant de recevoir une adresse valide.
enfait ce poiteur ne doit pas être déférencé avant de recevoir une adresse valide. Mais le faite que je considère l'initialisation d'un pointeur à NULL comme une manière de dire "la valeur contenue dans ce pointeur ne correspond pas à une adresse valable" alors là ce n'est vraiment necesaire que l'adresse affectée est non valable, d'où le but de ma question
je vous remercie pour votre réponse portable, et votre avis personnel, et je reformule ma question : si on affecte NULL à un pointeur, et on nous demande de mettre un X sur l'endroit où il pointe sur la zone mémoire, je mettrai où exactement le X, et pourquoi ?
amicalement,
++
Ou là ! Les pointeurs n'ont rien à voir avec les 'domaines numériques ou les maths traditionnelles... Ce sont des pointeurs, c'est tout. Leur valeur est soit valide (adresse d'une variable, retour de malloc() ou de fopen(), valeur d'un pointeur valide), soit invalide (NULL), soit indéterminée. C'est tout.mais si tu choisi la réponse 'nulle part' c'est comme tu as affecté la valeure 'vide' à une variable booléenne qui ne supporte que 0 ou 1 (vrai ou faux)
Tu peux le refaire en français de base, avec une concordance des temps cohérente...enfait ce poiteur ne doit pas être déférencé avant de recevoir une adresse valide. Mais le faite que je considère l'initialisation d'un pointeur à NULL comme une manière de dire "la valeur contenue dans ce pointeur ne correspond pas à une adresse valable" alors là ce n'est vraiment necesaire que l'adresse affectée est non valable, d'où le but de ma question
Tu es têtu. On se tue à dire que si un pointeur vaut NULL il ne doit pas être déréférencé (et tu l'as même toi même rappelé). Ta question n'a donc aucun sens, car <<si on affecte NULL à un pointeur, et on nous demande de mettre un X sur l'endroit où il pointe sur la zone mémoire>> signifie très exactement déréférencer. Comme déjà indiqué, le comportement est indéterminée, et il n'y a pas de réponse portable.je vous remercie pour votre réponse portable, et votre avis personnel, et je reformule ma question : si on affecte NULL à un pointeur, et on nous demande de mettre un X sur l'endroit où il pointe sur la zone mémoire, je mettrai où exactement le X, et pourquoi ?
Ca peut ne rien faire, détruire un vecteur à l'adresse physique 0, déclencher une exception, formater ton disque dur, envoyer les photos de toi en string léopard à ta mère...
En gros, on te dit 'rouler à contre sens sur l'autoroute, c'est mal' et tu demandes ce qui se passe si on le fait...
Ne le fait pas, c'est tout.
bonsoir,
euh, tu ne m'as pas bien compris..j'explique plus
+1, mais si tu as par exemple un pointeur qui pointe sur un char, cette adresse du pointeur est sauvegardée où dans la mémoire ? Et dans le cas de NULL que vaut cette valeure ? pas plus clair que çaEmmanuel Delahaye a écrit :
Ou là ! Les pointeurs n'ont rien à voir avec les 'domaines numériques ou les maths traditionnelles... Ce sont des pointeurs, c'est tout. Leur valeur est soit valide (adresse d'une variable, retour de malloc() ou de fopen(), valeur d'un pointeur valide), soit invalide (NULL), soit indéterminée. C'est tout.
sûrement y a quelque chose sauvegardée dans l'endroit où on sauvgarde une adresse valable, non ?Emmanuel Delahaye a écrit :
Tu es têtu. On se tue à dire que si un pointeur vaut NULL il ne doit pas être déréférencé (et tu l'as même toi même rappelé). Ta question n'a donc aucun sens, car <<si on affecte NULL à un pointeur, et on nous demande de mettre un X sur l'endroit où il pointe sur la zone mémoire>> signifie très exactement déréférencer. Comme déjà indiqué, le comportement est indéterminée, et il n'y a pas de réponse portable.c'est ce que je cherche..
je demande pas 'ce qui se passe si l'on fait..' mais plutôt 'quand l'autoroute est vide, c'est réalisable de rouler à contre sens ?'En gros, on te dit 'rouler à contre sens sur l'autoroute, c'est mal' et tu demandes ce qui se passe si on le fait...
je veux connaitre un truc, et je m'enfoue de se qui se passe après..Ca peut ne rien faire, détruire un vecteur à l'adresse physique 0, déclencher une exception, formater ton disque dur, envoyer les photos de toi en string léopard à ta mère...
et si tu caches de photo avec un string de léopard sur ton PC, vaut mieux que tu les efface, de crainte de tomber dans le cas que tu as déjà cité ; perso, je n'ai pas ce genre d'images, donc rien à avoir avec moi ...
++
Je pense que quand il parle de mettre un X, il veut parler schématiquement.
En gros si on représente la mémoire allouée au programme par un tableau sur un papier. Quelle serait la case qui contiendrait NULL.
C'est ça qu'il faut comprendre ou pas ?
re,
Skyrunner a écrit :
Je pense que quand il parle de mettre un X, il veut parler schématiquement.
En gros si on représente la mémoire allouée au programme par un tableau sur un papier. Quelle serait la case qui contiendrait NULL.
C'est ça qu'il faut comprendre ou pas ?exactement ça, je vois pas pour quoi ils n'ont pas compris le problème malgré qu'il est bien posé !
++
Si tu parles de l'adresse du char, elle est dans le pointeur. C'est fait pour.
http://emmanuel-delahaye.developpez.....htm#pointeurs
Elle vaut NULL. Aussi simple que ça.Et dans le cas de NULL que vaut cette valeure ? pas plus clair que ça
Dans le contexte pointeur, la norme dit que c'est la valeur 0 ou (void*)0. Attention, ça ne signifie nullement que la valeur binaire soit all-bit to 0. Ca dépend de l'implémentation, c'est pour ça qu'on ne peut pas répondre de façon générale. De toutes façons, cette question n'a pas d'intérêt, puisqu'une fois de plus, on ne doit pas déférérencer un pointeur valant NULL. C'est écrit noir sur blanc dans la norme qui définit le langage C. (C'est un comportement indéfini, autrement dit un bug).
C'est pas très clair... "l'endroit où on sauvgarde une adresse valable" c'est une variable de type pointeur... Tu veux savoir quelle est la valeur exacte ? On en sait rien et on s'en tape ...sûrement y a quelque chose sauvegardée dans l'endroit où on sauvgarde une adresse valable, non ?
Le problème est qu'on a aucun moyen de savoir si l'autoroute est vide.je demande pas 'ce qui se passe si l'on fait..' mais plutôt 'quand l'autoroute est vide, c'est réalisable de rouler à contre sens ?'
Et c'est quoi ce truc ?je veux connaitre un truc, et je m'enfoue de se qui se passe après..
bonsoir,
=> titre de discussionEt c'est quoi ce truc ?
Bon c'est plus convainquant comme ça
Merci pour tous ceux qui ont participé à la discussion.
cordialement,
++
Alors je t'ai déjà répondu. Sur le plan fonctionnel, il pointe 'nulle part'. Il est dit 'invalide'. L'avantage, c'est que c'est une valeur testable et qu'on a le droit d'écrire if (p != NULL), voire même if (p) (mais je ne le fais pas, trop laid).=> titre de discussion
C'est bien ce que j'avais compris. La représentation schématique de la mémoire sous forme de tableau est une abstraction et NULL est une abstraction de "Nul part", ou "Non valide".
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
bonsoir,
la phrase en rouge dépend de la technologie de la mémoire elle meme. Enfait il est 'interdit' de déférérencer un pointeur valant NULL (puisqu'il est NullEmmanuel Delahaye a écrit :
Dans le contexte pointeur, la norme dit que c'est la valeur 0 ou (void*)0. Attention, ça ne signifie nullement que la valeur binaire soit all-bit to 0. Ca dépend de l'implémentation, c'est pour ça qu'on ne peut pas répondre de façon générale.
++
Concernant la valeur du pointeur, matériellement, ça peut être n'importe quoi.
Mais logiciellement, elle correspond à zéro, ce qui explique que if(p) marche.
PS: Un pointeur NULL peut ne même pas pointer sur de la mémoire. Sur une architecture à un seul plan (les 68000, par exemple, et surtout pas les Intel ou Zilog), la mémoire peut n'occuper qu'une seule partie de l'espace d'adressage.
Et, je ne parle même pas encore de la mémoire virtuelle, qui peut mettre n'importe quoi à l'"adresse" d'un pointeur NULL...
PS: Skyrunner: Aucune case ne "contiendrait" NULL. Mais il peut très bien y avoir une case "spéciale" ou non à l'adresse NULL, ou bien pas de case du tout (que du vide, entrainant non pas une AccessViolation/SegFault mais un truc du genre Bus Error)...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
NULL n'étant pas une adresse valide, il ne risque pas de pointer sur quoi que ce soit de tangible, en tout cas du point de vue du C. Les détails physiques ne nous concerne pas, de toutes façons, on y a pas accès de façon portable.la phrase en rouge dépend de la technologie de la mémoire elle meme. Enfait il est 'interdit' de déférérencer un pointeur valant NULL (puisqu'il est Null
Il faut prendre un peu de hauteur. Le C est un langage de haut niveau. OK, pas très haut, mais suffisamment pour que les aspect matériels soient complètement 'abstractisés'. Alors STP, ne viens pas nous parler de la mémoire physique sur un forum C. Ca n'existe pas.
La vrai seule et unique raison pour laquelle il ne faut pas déréférencer un pointeur valant NULL, c'est qu'il est écrit dans la norme que ça provoque un comportement indéfini. C'est tout. Ca n'a strictement rien à voir avec la mémoire physique ou le système. Le C est indépendant de la machine réelle. Il faut arriver à se mettre ça dans le crane.
C != Assembleur. OK ?
bonjour,
le C est un langage plus haut niveau que assembleur, ça c'est clair, de façon que les aspect matériels sont complètement abstractisés! bon d'accord..
je suis 100% daccord avec la NON déférenciation d'un pointeur valant NULL. La norme le dit, moi j'ai pas dis le contraire, et plutôt tous le monde le sait !!! ça ne sert à rien de la répéter chaque fois.Emmanuel Delahaye a écrit :
La vrai seule et unique raison pour laquelle il ne faut pas déréférencer un pointeur valant NULL, c'est qu'il est écrit dans la norme que ça provoque un comportement indéfini.
il se peut que j'ai mal choisi le thème de Forum (C) où je devrai poster ma discussion, mais ça ne veut pas dire que je n'étudis pas le comportement du compilateur C. Enfait c'est pas le langage C qui me gêne, je me concentre plus sur le compilateur C et sa gestion de mémoire.. le soft (code) ça n'a rien à avoir dans ce problème puisque if(p) fonctionne très bien
oui c'est différent, mais malgré ça c'était un bon exemple ! Médinoc a bien compris le soucisEmmanuel Delahaye a écrit :
C != Assembleur
les motorola 68000 peuvent adresser sur 24bit (ya les 8 derniers bits hinébiés), mais parfois, la mémoire n'utilise que 16bits du poids faible (contrainte d'éspace mémoire limite)..
bon comme ça on s'éloigne un peu du C
c'est chaude encore une fois cette discussion
merci pour vos participations
++
Non, le forum était adéquate et tu as eu ta réponse. Je ne vois pas ce que tu cherches de plus.
C'est pas très clair. Qu'est-ce que le compilateur a à voir avec ta question ? Et puis il n'y a pas 'un' compilateir C. Il y a des dizaines, et ils ont tous un comportement différent.mais ça ne veut pas dire que je n'étudis pas le comportement du compilateur C. Enfait c'est pas le langage C qui me gêne, je me concentre plus sur le compilateur C et sa gestion de mémoire.. le soft (code) ça n'a rien à avoir dans ce problème puisque if(p) fonctionne très bien
- Selon le processeur cible
- Selon le système
- Selon la version du langage...
En plus chaque compilateur avec des réglages qui ajustent le comportement...
De quel compilateur parles-tu et avec quels réglages ?
Tu as une nouvelle question ?
bonsoir,
oui biensur, je précise..Emmanuel Delahaye a écrit :
C'est pas très clair. Qu'est-ce que le compilateur a à voir avec ta question ? Et puis il n'y a pas 'un' compilateir C. Il y a des dizaines, et ils ont tous un comportement différent.
Selon le processeur cible
Selon le système
Selon la version du langage...
En plus chaque compilateur avec des réglages qui ajustent le comportement...
De quel compilateur parles-tu et avec quels réglages ?
- IDE : turbo C++ v4.5 (sous win biensur)
- OS : win XP SP2
- j'ai rien changé comme réglages, il est installé par défaut..
++
Et /dev/null c'est un trou noir ?
En quelque sorte, oui. Ce qui tombe dedans n'en ressort jamais...
(Quoique la théorie des trous noirs implique celle des fontaines blanches...)
Répondre avec citation
Partager