bonsoir,
tout est écrit dans le titre ;) si j'initialise un poiteur sur NULL, il pointe où réellement sur la mémoire?
merci..
Version imprimable
bonsoir,
tout est écrit dans le titre ;) si j'initialise un poiteur sur NULL, il pointe où réellement sur la mémoire?
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.Citation:
Envoyé par Blue_Strike
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
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) ;) autrement dit, on connait tous que 'vide' ou 'nulle part' n'exsite pas dans un domaine numérique.. ou bien 0 ou bien 1.Citation:
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 ! ;)Citation:
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.Citation:
Envoyé par Blue_Strike
Tu peux le refaire en français de base, avec une concordance des temps cohérente...Citation:
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.Citation:
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 ça ;)Citation:
Emmanuel 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 ? 8O c'est ce que je cherche..Citation:
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.
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 ?' :aie:Citation:
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..Citation:
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 ... :mouarf:
++
Je pense que quand il parle de mettre un X, il veut parler schématiquement.Citation:
Envoyé par Emmanuel Delahaye
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,
:hola: exactement ça, je vois pas pour quoi ils n'ont pas compris le problème malgré qu'il est bien posé ! :koi:Citation:
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 ?
++
Si tu parles de l'adresse du char, elle est dans le pointeur. C'est fait pour.Citation:
Envoyé par Blue_Strike
http://emmanuel-delahaye.developpez.....htm#pointeurs
Elle vaut NULL. Aussi simple que ça.Citation:
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 ...Citation:
sûrement y a quelque chose sauvegardée dans l'endroit où on sauvgarde une adresse valable, non ? 8O c'est ce que je cherche..
Le problème est qu'on a aucun moyen de savoir si l'autoroute est vide.Citation:
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 ?' :aie:
Et c'est quoi ce truc ?Citation:
je veux connaitre un truc, et je m'enfoue de se qui se passe après..
bonsoir,
=> titre de discussion ;)Citation:
Et c'est quoi ce truc ?
Bon c'est plus convainquant comme ça ;) enfait j'ai compris de quoi il s'agit et comment se comporte les pointeurs dependant des adresses..
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).Citation:
Envoyé par Blue_Strike
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".Citation:
Envoyé par Skyrunner
Thierry
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 Null ;) ) ; Mais en réalité, losque le pointeur vaut Null, il pointe sur une zone spéciale de la mémoire dépendant de sa technologie comme j'avais dis (d'où à lire la phrase rouge) .. cette zone n'est pas utilisable comme une simple case mémoire, elle est morte, et seul le constructeur connaît son emplacement.. c'est pourquoi on ne doit jamais déférérencer un pointeur valant NULL ;)Citation:
Emmanuel 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)...
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.Citation:
Envoyé par Blue_Strike
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.Citation:
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 soucis ;)Citation:
Emmanuel 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 :aie: restons sur le compilateur C ;)
c'est chaude encore une fois cette discussion :mrgreen:
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.Citation:
Envoyé par Blue_Strike
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.Citation:
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..Citation:
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...Citation:
Envoyé par |PaRa-BoL
(Quoique la théorie des trous noirs implique celle des fontaines blanches...)
Sans rapport avec NULL... au sens du langage C.Citation:
Envoyé par |PaRa-BoL
Thierry
bonsoir,
oui, ça n'a rien à avoir avec le problème de la discussion posé sur "NULL"..Citation:
mujigka a écrit :
Sans rapport avec NULL... au sens du langage C.Citation:
Citation:
|PaRa-BoL a écrit :
Et /dev/null c'est un trou noir ?
Thierry
@Emmanuel Delahaye : bah tu as la répense concernant ta question ! ;) :
++Citation:
oui biensur, je précise..
- 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..
Citation:
Envoyé par Blue_Strike
il ne pointe nul part :autrement dit y a pas de case memoire reservée pour un pointeur NULL.
mais plutot un pointeur NULL vaut en principe 0 mais cette case n'est pas reservée pour les variable.
important: on sait q'un pointeur vaut NULL par sa valeur (0)
pas par ce que contient l'adresse (0).
+1Citation:
Envoyé par denoo
stddef.h
Code:
2
3
4
5
Oui, on le sait bien. Et ?Citation:
Envoyé par |PaRa-BoL
Et rien, je confirme juste par un quote le message précédent...
Alors il faut apprendre à citer : http://www.developpez.net/forums/ima...tons/quote.gifCitation:
Envoyé par |PaRa-BoL
bonsoir,
mais elle existe qd même !Citation:
denoo a écrit :
il ne pointe nul part :autrement dit y a pas de case memoire reservée pour un pointeur NULL.
mais plutot un pointeur NULL vaut en principe 0 mais cette case n'est pas reservée pour les variable.
important: on sait q'un pointeur vaut NULL par sa valeur (0)
pas par ce que contient l'adresse (0).
+9999
ça c'est au niveau soft ! je parle réellement qu'est ce qui se passe, vous me comprenez ?! (niveau architecture plus que soft)
bon j'ai une question : si un pointeur pointe sur une variable int par exemple, l'adresse de ce pointeur se trouve où ? c'est à dire où elle est stockée ?
et si un pointeur vaut NULL, autrement dit (0), est ce que celà est l'équivalent à 0000x0000 ??
@denoo : tu appelle quoi une case qui n'est pas reservée pour les variables ?
++
Pas forcément. Ca dépend des machines. Et si il y a une MMU ou pas etc. Le 0 de la MMU n'est pas le 0 physique...Citation:
Envoyé par Blue_Strike
Il peut aussi en exister un grand nombre, comme en x86 mode réel modèle de mémoire small (DS:0000) avec DS valant de 0 à 0xFFFF
Le pointeur étant une variable, il a une adresse. Une adresse est une expression constante. Elle n'est pas 'stockée'. Vu de l'assembleur (langage machine), c'est une valeur immédiate.Citation:
bon j'ai une question : si un pointeur pointe sur une variable int par exemple, l'adresse de ce pointeur se trouve où ? c'est à dire où elle est stockée ?
En valeur, oui, en adresse physique, non, pas automatiquement. C'est vrai dans certains cas.Citation:
et si un pointeur vaut NULL, autrement dit (0), est ce que celà est l'équivalent à 0000x0000 ??
De la mémoire libre (heap ou tas ou free store). C'est la zone allouable par malloc().Citation:
@denoo : tu appelle quoi une case qui n'est pas reservée pour les variables ?
+1Citation:
Emmanuel Delahaye a écrit :
Pas forcément. Ca dépend des machines. Et si il y a une MMU ou pas etc. Le 0 de la MMU n'est pas le 0 physique...Citation:
Citation:
Blue_Strike a écrit :
mais elle existe qd même !
ça existe en motorola aussi (68000)..Citation:
Il peut aussi en exister un grand nombre, comme en x86 mode réel modèle de mémoire small (DS:0000) avec DS valant de 0 à 0xFFFF
oui mais même la valeure immédiate est "stocké" disons sauvegardée qque part non ?! ;) dans la RAM par exeple, sinon, si tu mets :Citation:
Le pointeur étant une variable, il a une adresse. Une adresse est une expression constante. Elle n'est pas 'stockée'. Vu de l'assembleur (langage machine), c'est une valeur immédiate.
int *k;
int i=59;
*k=i;
printf("%p",k); => ça doit afficher l'adresse de i, mais qui est reprentée par k, alors là, comment le compilateur trouve la valeur? ou coment il a connu que k est l'adresse de i ? sûrement qque chose a changé en executant cette instruction : *k=i; ;)
Ok pour le reste ;)
++
Soit ce petit programme:Citation:
Envoyé par Blue_Strike
Il produit la sortie suivante:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
On y voit que les valeurs de a, pa et pb sont stockées sur la pile aux adresses 0xbfaec314, 0xbfaec310 et 0xbfaec30c respectivement. On voit très clairement que pa pointe sur a. La valeur stockée dans pb à l'adresse 0xbfaec30c est NULL, c'est à dire 0x00000000 sur ma machine où les pointeurs sont codés sur 32 bits. Si tu regarde le code assembleur généré (dans mon cas par gcc), tu peux voir que ce ne sont que des valeurs binaires codées sur 4 octets.Code:
2
3
4
Voici le code assembleur GNU correspondant à la fonction affiche_pile():
Tu peux voir qu'il n'y a pas de différence entre la valeur 10 stockée dans a, qui dans le programme C est de type int, et la valeur 0 (i.e. NULL) stockée dans pb. Autrement dit, le types des variables n'existe plus dans ce code assembleur. Rien ne dit que la valeur à l'adresse -12(%ebp) (qui correspond ici à pb) est un pointeur et que cette valeur correspond à une adresse qui peut être déréférencée. C'est le compilateur qui décide si on peut déréférencer cette valeur, et génère le cas échéant le code assembleur permettant d'accéder à la valeur située à l'adresse stockée dans pb. Dans le cas, du pointeur NULL, le compilateur sait que ce n'est pas une adresse valable et son comportement est indéterminé.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14affiche_pile: pushl %ebp movl %esp, %ebp subl $40, %esp # Ici, on stocke la valeur 10 dans a movl $10, -4(%ebp) # On calcul l'adresse de a et on stocke cette valeur dans le # registre EAX (architecture IA-32) leal -4(%ebp), %eax # On stocke l'adresse de a dans pa movl %eax, -8(%ebp) # Et maintenant, on stocke la valeur 0 (NULL) dans pb movl $0, -12(%ebp) #...
Pour conclure, tout ceci fait apparaître que NULL correspond à la valeur 0x00000000 (sur mon PIII) et que cette valeur est dans le cas de notre exemple, stockée sur la pile. Ainsi NULL n'est qu'une valeur comme la valeur 10 stockée dans la variable a, mais ne pointe NULLE PART. C'est le compilateur qui décide si cette valeur peut représenter une adresse mémoire ou pas (lr compilateur sait que 10 n'est pas une adresse, car la valeur stockée dans a est de type int). Dans le cas de NULL, cela ne représente pas une adresse valable. Par suite, la question de savoir où pointe NULL est un non sens.
Thierry
Attend toi à des surprises ;)Citation:
Envoyé par Blue_Strike
Elle est écrite en dur dans le code machine. Il y a des champs de bits pour ça dans les instructions. Ouvrir son livre d'assembleur...Citation:
Envoyé par Blue_Strike
Comme dirait ma fille 'explosition :!:' k est un pointeur non initialisé, son déréférencement invoque un comportement indéterminé. Tout le raisonnement de la suite est faux.Citation:
dans la RAM par exeple, sinon, si tu mets :
int *k;
int i=59;
*k=i;
J'ai l'impression que la manipulation des pointeurs n'est pas très claire pour toi. Dans le micro bout de code ci-dessus, jamais le pointeur k ne reçois l'adresse de i. *k = i; correspond à un déréférencement de k (non initialisé i.e. comportement indéfini) pour stoquer la valeur de i à l'adresse contenue dans k. C'est pas du tout ce que tu décris. Regarde mon dernier post et tu comprendras mieux...Citation:
Envoyé par Blue_Strike
Voici ce que donne la sortie console:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Et voici l'assembleur généré pour la fonction comprendre_mem():Code:
2
Il n'y a absolument aucune magie nulle part! k est une variable située sur la pile qui contient une valeur qui correspond à l'adresse de i. L'emplacement mémoire de i est ici situé 4 "cases plus haut" que k. Ainsi, à l'adresse de k (0xbfceae60), on trouve bien la valeur 0xbfceae64 qui correspond à l'adresse de la variable i située 4 octets plus "haut".Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25comprendre_mem: pushl %ebp movl %esp, %ebp subl $40, %esp # La valeur 59 est stockée sur la pile dans la valiable i movl $59, -4(%ebp) # L'adresse de i est calculée et sa valeur est plcée dans EAX leal -4(%ebp), %eax # L'adresse de i est copiée dans sur la pile dans k movl %eax, -8(%ebp) # Toute la suite concerne printf() movl -8(%ebp), %eax movl %eax, 8(%esp) leal -8(%ebp), %eax movl %eax, 4(%esp) movl $.LC0, (%esp) call printf movl -4(%ebp), %eax movl %eax, 8(%esp) leal -4(%ebp), %eax movl %eax, 4(%esp) movl $.LC1, (%esp) call printf leave ret
Thierry
Thierry