Ce qui me gène c'est pourquoi, dans ce cas, memcmp prend en argument des
void* et non des char* ?
La raison est que la conversion de toto* à void* est silencieuse, ce qui
ne serait pas le cas d'une conversion directe (implicite) vers char*
Maintenant, je ne comprend pas en quoi cela pourrait te *gêner* ?
Ce qui me gène c'est pourquoi, dans ce cas, memcmp prend en argument des
void* et non des char* ?
La raison est que la conversion de toto* à void* est silencieuse, ce qui
ne serait pas le cas d'une conversion directe (implicite) vers char*
Maintenant, je ne comprend pas en quoi cela pourrait te *gêner* ?
Ce qui me gène c'est pourquoi, dans ce cas, memcmp prend en argument des
void* et non des char* ?
La raison est que la conversion de toto* à void* est silencieuse, ce qui
ne serait pas le cas d'une conversion directe (implicite) vers char*
Maintenant, je ne comprend pas en quoi cela pourrait te *gêner* ?
Bonjour,
le 27/08/2013 à 11:47, Antoine Leca a écrit dans le message
<kvhsk5$n1o$ :Ce qui me gène c'est pourquoi, dans ce cas, memcmp prend en argument des
void* et non des char* ?
La raison est que la conversion de toto* à void* est silencieuse, ce qui
ne serait pas le cas d'une conversion directe (implicite) vers char*
Maintenant, je ne comprend pas en quoi cela pourrait te *gêner* ?
Ce qui me gêne, c'est que lorsque je vois une fonction qui prend en
argument un void*, je m'attends à ce qu'elle marche avec n'importe quoi.
Or ici ce n'est clairement pas le cas et, si j'ai bien compris toute la
discussion, le comportement n'est défini qu'avec des (unsigned) char*
puisque tous les autres types (non entiers je pense) peuvent avoir une
représentation en mémoire différente tout en ayants la même valeur (==).
Bonjour,
le 27/08/2013 à 11:47, Antoine Leca a écrit dans le message
<kvhsk5$n1o$1@shakotay.alphanet.ch> :
Ce qui me gène c'est pourquoi, dans ce cas, memcmp prend en argument des
void* et non des char* ?
La raison est que la conversion de toto* à void* est silencieuse, ce qui
ne serait pas le cas d'une conversion directe (implicite) vers char*
Maintenant, je ne comprend pas en quoi cela pourrait te *gêner* ?
Ce qui me gêne, c'est que lorsque je vois une fonction qui prend en
argument un void*, je m'attends à ce qu'elle marche avec n'importe quoi.
Or ici ce n'est clairement pas le cas et, si j'ai bien compris toute la
discussion, le comportement n'est défini qu'avec des (unsigned) char*
puisque tous les autres types (non entiers je pense) peuvent avoir une
représentation en mémoire différente tout en ayants la même valeur (==).
Bonjour,
le 27/08/2013 à 11:47, Antoine Leca a écrit dans le message
<kvhsk5$n1o$ :Ce qui me gène c'est pourquoi, dans ce cas, memcmp prend en argument des
void* et non des char* ?
La raison est que la conversion de toto* à void* est silencieuse, ce qui
ne serait pas le cas d'une conversion directe (implicite) vers char*
Maintenant, je ne comprend pas en quoi cela pourrait te *gêner* ?
Ce qui me gêne, c'est que lorsque je vois une fonction qui prend en
argument un void*, je m'attends à ce qu'elle marche avec n'importe quoi.
Or ici ce n'est clairement pas le cas et, si j'ai bien compris toute la
discussion, le comportement n'est défini qu'avec des (unsigned) char*
puisque tous les autres types (non entiers je pense) peuvent avoir une
représentation en mémoire différente tout en ayants la même valeur (==).
In article <kvht9h$qqb$,
Antoine Leca wrote:candide écrivit :Le 20/08/2013 20:06, Tonton Th a écrit :Pour les structures, il ne faut surtout pas oublier les
éventuels octets de remplissage dont les valeurs sont
totalement imprévisibles (voir le théorème de Murphy)
La parade classique étant alors de zéroïfier la structure via memset.
Mais d'après certains sur clc, cela ne garantit pas de la
non-réapparition de bits de padding aléatoires lors de l'affectation
ultérieure d'un membre de la structure. Donc hacher des structures de
façon standard semble être assez acrobatique : après chaque affectation
de membre, il faudrait zéroïfier entre les différents membres de la
dite-structure.
Comme tu viens de l'écrire deux phrases avant, on ne sait pas (de
manière portable, c'est-à-dire sans intervention explicite du
compilateur) « zéroïfier » les bits de remplissage ; une solution est de
sérialiser les données structurées, ce qui élimine de fait les octets de
remplissage, mais ne répond pas à tous les cas, cf. flottants.
Ce que tu ecris est un peu ambigu. memset saura zeroifier la totalite d'une
structure, dans un sens tres precis (mettre tous les octets a zero).
erreur de ma part, ca doit marcher sur les implementations freestanding
(flemme de sortir la norme et verifier, mais ca me surprendrait que
memset/memcpy/memmove ne fasse pas partie du coeur des fonctions garanties).
Ce que ca veut dire de precis pour les valeurs, ca par contre, c'est une
autre paire de manches... meme sans les flottants, ne pas oublier que la
representation d'un pointeur nul n'est pas garantie d'etre "tous les bits a 0".
Je ne suis meme pas sur que ca soit applicable pour les entiers. Me semble
que la norme est tres precise dans son vocabulaire concernant les unsigned int,
mentionnant explicitement la possibilite d'avoir des bits en plus...
In article <kvht9h$qqb$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
candide écrivit :
Le 20/08/2013 20:06, Tonton Th a écrit :
Pour les structures, il ne faut surtout pas oublier les
éventuels octets de remplissage dont les valeurs sont
totalement imprévisibles (voir le théorème de Murphy)
La parade classique étant alors de zéroïfier la structure via memset.
Mais d'après certains sur clc, cela ne garantit pas de la
non-réapparition de bits de padding aléatoires lors de l'affectation
ultérieure d'un membre de la structure. Donc hacher des structures de
façon standard semble être assez acrobatique : après chaque affectation
de membre, il faudrait zéroïfier entre les différents membres de la
dite-structure.
Comme tu viens de l'écrire deux phrases avant, on ne sait pas (de
manière portable, c'est-à-dire sans intervention explicite du
compilateur) « zéroïfier » les bits de remplissage ; une solution est de
sérialiser les données structurées, ce qui élimine de fait les octets de
remplissage, mais ne répond pas à tous les cas, cf. flottants.
Ce que tu ecris est un peu ambigu. memset saura zeroifier la totalite d'une
structure, dans un sens tres precis (mettre tous les octets a zero).
erreur de ma part, ca doit marcher sur les implementations freestanding
(flemme de sortir la norme et verifier, mais ca me surprendrait que
memset/memcpy/memmove ne fasse pas partie du coeur des fonctions garanties).
Ce que ca veut dire de precis pour les valeurs, ca par contre, c'est une
autre paire de manches... meme sans les flottants, ne pas oublier que la
representation d'un pointeur nul n'est pas garantie d'etre "tous les bits a 0".
Je ne suis meme pas sur que ca soit applicable pour les entiers. Me semble
que la norme est tres precise dans son vocabulaire concernant les unsigned int,
mentionnant explicitement la possibilite d'avoir des bits en plus...
In article <kvht9h$qqb$,
Antoine Leca wrote:candide écrivit :Le 20/08/2013 20:06, Tonton Th a écrit :Pour les structures, il ne faut surtout pas oublier les
éventuels octets de remplissage dont les valeurs sont
totalement imprévisibles (voir le théorème de Murphy)
La parade classique étant alors de zéroïfier la structure via memset.
Mais d'après certains sur clc, cela ne garantit pas de la
non-réapparition de bits de padding aléatoires lors de l'affectation
ultérieure d'un membre de la structure. Donc hacher des structures de
façon standard semble être assez acrobatique : après chaque affectation
de membre, il faudrait zéroïfier entre les différents membres de la
dite-structure.
Comme tu viens de l'écrire deux phrases avant, on ne sait pas (de
manière portable, c'est-à-dire sans intervention explicite du
compilateur) « zéroïfier » les bits de remplissage ; une solution est de
sérialiser les données structurées, ce qui élimine de fait les octets de
remplissage, mais ne répond pas à tous les cas, cf. flottants.
Ce que tu ecris est un peu ambigu. memset saura zeroifier la totalite d'une
structure, dans un sens tres precis (mettre tous les octets a zero).
erreur de ma part, ca doit marcher sur les implementations freestanding
(flemme de sortir la norme et verifier, mais ca me surprendrait que
memset/memcpy/memmove ne fasse pas partie du coeur des fonctions garanties).
Ce que ca veut dire de precis pour les valeurs, ca par contre, c'est une
autre paire de manches... meme sans les flottants, ne pas oublier que la
representation d'un pointeur nul n'est pas garantie d'etre "tous les bits a 0".
Je ne suis meme pas sur que ca soit applicable pour les entiers. Me semble
que la norme est tres precise dans son vocabulaire concernant les unsigned int,
mentionnant explicitement la possibilite d'avoir des bits en plus...
Oui, *tous* ; et l'idée est de ne mettre à zéro *que* les octets de
remplissage, puisqu'on souhaite préserver la valeur des membres de la
structure...
Oui, *tous* ; et l'idée est de ne mettre à zéro *que* les octets de
remplissage, puisqu'on souhaite préserver la valeur des membres de la
structure...
Oui, *tous* ; et l'idée est de ne mettre à zéro *que* les octets de
remplissage, puisqu'on souhaite préserver la valeur des membres de la
structure...
Le vendredi 30 août 2013 10:14:43 UTC+2, Antoine Leca a écrit :Oui, *tous* ; et l'idée est de ne mettre à zéro *que* les octets de
remplissage, puisqu'on souhaite préserver la valeur des membres de la
structure...
Et ce n'est pas possible (de façon portable) ?
La solution naïve ne marche pas ? La solution naïve c'est de zéroifier
séquentiellement entre la fin d'un membre et le début du suivant les
éventuels bits de padding,
pour ça j'ai juste besoin de connaître les adresses des début et fin
de chaque zone de padding ce qui est possible en utilisant sizeof
sur les membres de la structures.
Le vendredi 30 août 2013 10:14:43 UTC+2, Antoine Leca a écrit :
Oui, *tous* ; et l'idée est de ne mettre à zéro *que* les octets de
remplissage, puisqu'on souhaite préserver la valeur des membres de la
structure...
Et ce n'est pas possible (de façon portable) ?
La solution naïve ne marche pas ? La solution naïve c'est de zéroifier
séquentiellement entre la fin d'un membre et le début du suivant les
éventuels bits de padding,
pour ça j'ai juste besoin de connaître les adresses des début et fin
de chaque zone de padding ce qui est possible en utilisant sizeof
sur les membres de la structures.
Le vendredi 30 août 2013 10:14:43 UTC+2, Antoine Leca a écrit :Oui, *tous* ; et l'idée est de ne mettre à zéro *que* les octets de
remplissage, puisqu'on souhaite préserver la valeur des membres de la
structure...
Et ce n'est pas possible (de façon portable) ?
La solution naïve ne marche pas ? La solution naïve c'est de zéroifier
séquentiellement entre la fin d'un membre et le début du suivant les
éventuels bits de padding,
pour ça j'ai juste besoin de connaître les adresses des début et fin
de chaque zone de padding ce qui est possible en utilisant sizeof
sur les membres de la structures.
Et ce n'est pas possible (de façon portable) ? La solution naïve ne
marche pas ? La solution naïve c'est de zéroifier séquentiellement entre
la fin d'un membre et le début du suivant les éventuels bits de padding,
pour ça j'ai juste besoin de connaître les adresses des début et fin de
chaque zone de padding ce qui est possible en utilisant sizeof sur les
membres de la structures.
Et ce n'est pas possible (de façon portable) ? La solution naïve ne
marche pas ? La solution naïve c'est de zéroifier séquentiellement entre
la fin d'un membre et le début du suivant les éventuels bits de padding,
pour ça j'ai juste besoin de connaître les adresses des début et fin de
chaque zone de padding ce qui est possible en utilisant sizeof sur les
membres de la structures.
Et ce n'est pas possible (de façon portable) ? La solution naïve ne
marche pas ? La solution naïve c'est de zéroifier séquentiellement entre
la fin d'un membre et le début du suivant les éventuels bits de padding,
pour ça j'ai juste besoin de connaître les adresses des début et fin de
chaque zone de padding ce qui est possible en utilisant sizeof sur les
membres de la structures.
Définis « fin d'un membre » ?
Mmmm... Avec la méthode dont tu parles (écrire des octets à 0), au plus
tu vas pouvoir éradiquer les _octets_ de bourrage, c'est-à-dire les
octets que le compilateur rajoute entre les membres pour différentes
raisons, de performance ou pour pouvoir avoir des accès correctement
alignés aux membres ou aux éléments d'un tableau de la structure.
Les _bits_ de remplissage sont pour moi un autre concept, celui de bits
sans signification sémantique mais qui font partie de la représentation
des objets en mémoire. On peut avoir des bits de parité, ou des bits
imposé par le matériel, comme par exemple le cas (pas habituel en C,
mais qui peut exister avec d'autres langages) des valeur booléennes
stockées de manière comprimée à 8 par octet, quand on les manipule de
manière individuelle il faut bien « gâcher » 7 bit par objet...
pour ça j'ai juste besoin de connaître les adresses des début et fin
de chaque zone de padding ce qui est possible en utilisant sizeof
sur les membres de la structures.
Il y a au moins trois handicaps à ta solution : cela ne marche dans le
cas général ni pour les champs de bits, ni pour les unions, ni pour les
structures membres d'une autre structure (il faudrait récurer pour
déterminer le bourrage à la fin de la structure).
Par ailleurs, je ne vois pas ce qui oblige le compilateur à utiliser
*tout* l'espace indiqué par sizeof(type) pour ranger chaque membre ; par
exemple 3*sizeof(long double) pour stocker 3 membres long double.
Exemple : avec certains compilateurs amd64, les long doubles sont des
flottants IEEE étendus sur 80 bits (10 octets) ; en général, un élément
isolé est stocké sur 16 octets pour être aligné sur une adresse 64 bits,
ce qui est largement plus facile à manipuler pour le compilateur
(alignement sur la pile); mais pour le CPU, cet alignement n'a pas
vraiment d'importance, donc pour une structure avec 3 membres long
double, il n'est pas nécessaire de gâcher tant d'espace et on peut
imaginer de ranger les membres bord à bord, avec juste 2 octets au bout,
total 30+2 octets soit 2*sizeof(long double) !
Définis « fin d'un membre » ?
Mmmm... Avec la méthode dont tu parles (écrire des octets à 0), au plus
tu vas pouvoir éradiquer les _octets_ de bourrage, c'est-à-dire les
octets que le compilateur rajoute entre les membres pour différentes
raisons, de performance ou pour pouvoir avoir des accès correctement
alignés aux membres ou aux éléments d'un tableau de la structure.
Les _bits_ de remplissage sont pour moi un autre concept, celui de bits
sans signification sémantique mais qui font partie de la représentation
des objets en mémoire. On peut avoir des bits de parité, ou des bits
imposé par le matériel, comme par exemple le cas (pas habituel en C,
mais qui peut exister avec d'autres langages) des valeur booléennes
stockées de manière comprimée à 8 par octet, quand on les manipule de
manière individuelle il faut bien « gâcher » 7 bit par objet...
pour ça j'ai juste besoin de connaître les adresses des début et fin
de chaque zone de padding ce qui est possible en utilisant sizeof
sur les membres de la structures.
Il y a au moins trois handicaps à ta solution : cela ne marche dans le
cas général ni pour les champs de bits, ni pour les unions, ni pour les
structures membres d'une autre structure (il faudrait récurer pour
déterminer le bourrage à la fin de la structure).
Par ailleurs, je ne vois pas ce qui oblige le compilateur à utiliser
*tout* l'espace indiqué par sizeof(type) pour ranger chaque membre ; par
exemple 3*sizeof(long double) pour stocker 3 membres long double.
Exemple : avec certains compilateurs amd64, les long doubles sont des
flottants IEEE étendus sur 80 bits (10 octets) ; en général, un élément
isolé est stocké sur 16 octets pour être aligné sur une adresse 64 bits,
ce qui est largement plus facile à manipuler pour le compilateur
(alignement sur la pile); mais pour le CPU, cet alignement n'a pas
vraiment d'importance, donc pour une structure avec 3 membres long
double, il n'est pas nécessaire de gâcher tant d'espace et on peut
imaginer de ranger les membres bord à bord, avec juste 2 octets au bout,
total 30+2 octets soit 2*sizeof(long double) !
Définis « fin d'un membre » ?
Mmmm... Avec la méthode dont tu parles (écrire des octets à 0), au plus
tu vas pouvoir éradiquer les _octets_ de bourrage, c'est-à-dire les
octets que le compilateur rajoute entre les membres pour différentes
raisons, de performance ou pour pouvoir avoir des accès correctement
alignés aux membres ou aux éléments d'un tableau de la structure.
Les _bits_ de remplissage sont pour moi un autre concept, celui de bits
sans signification sémantique mais qui font partie de la représentation
des objets en mémoire. On peut avoir des bits de parité, ou des bits
imposé par le matériel, comme par exemple le cas (pas habituel en C,
mais qui peut exister avec d'autres langages) des valeur booléennes
stockées de manière comprimée à 8 par octet, quand on les manipule de
manière individuelle il faut bien « gâcher » 7 bit par objet...
pour ça j'ai juste besoin de connaître les adresses des début et fin
de chaque zone de padding ce qui est possible en utilisant sizeof
sur les membres de la structures.
Il y a au moins trois handicaps à ta solution : cela ne marche dans le
cas général ni pour les champs de bits, ni pour les unions, ni pour les
structures membres d'une autre structure (il faudrait récurer pour
déterminer le bourrage à la fin de la structure).
Par ailleurs, je ne vois pas ce qui oblige le compilateur à utiliser
*tout* l'espace indiqué par sizeof(type) pour ranger chaque membre ; par
exemple 3*sizeof(long double) pour stocker 3 membres long double.
Exemple : avec certains compilateurs amd64, les long doubles sont des
flottants IEEE étendus sur 80 bits (10 octets) ; en général, un élément
isolé est stocké sur 16 octets pour être aligné sur une adresse 64 bits,
ce qui est largement plus facile à manipuler pour le compilateur
(alignement sur la pile); mais pour le CPU, cet alignement n'a pas
vraiment d'importance, donc pour une structure avec 3 membres long
double, il n'est pas nécessaire de gâcher tant d'espace et on peut
imaginer de ranger les membres bord à bord, avec juste 2 octets au bout,
total 30+2 octets soit 2*sizeof(long double) !
Le 30/08/2013 16:48, Antoine Leca a écrit :Définis « fin d'un membre » ?
Naïvement, ce qui commence à a+n où a est l'adresse du mem bre et n sa
taille.Mmmm... Avec la méthode dont tu parles (écrire des octets à 0), au plus
tu vas pouvoir éradiquer les _octets_ de bourrage, c'est-à -dir e les
octets que le compilateur rajoute entre les membres pour différentes
raisons, de performance ou pour pouvoir avoir des accès correctement
alignés aux membres ou aux éléments d'un tableau de la st ructure.
Les _bits_ de remplissage sont pour moi un autre concept, celui de bits
sans signification sémantique mais qui font partie de la repré sentation
des objets en mémoire. On peut avoir des bits de parité, ou de s bits
imposé par le matériel, comme par exemple le cas (pas habituel en C,
mais qui peut exister avec d'autres langages) des valeur booléennes
stockées de manière comprimée à 8 par octet, quand o n les manipule de
manière individuelle il faut bien « gâcher » 7 bit p ar objet...
Tu veux dire alors que ces bits (parité, matériel) sont "incont rôlables" et
vont revenir même si on les éradique ?
Sinon, quelqu'un pourrait-il citer le passage de la norme qui montre que
les bits entre les membres d'une structure peuvent être modifié s Ã
n'importe quel accès au membre ? cf. ce que j'avais rapporté de mes
lectures sur clc mais qui ne donnaient aucune référence.
à ce que j'ai compris, il existe au plus trois types de
bits : bit de valeur, bit de signe et bit de padding. D'après ce que j'ai
lu (entre autres, les commentaires du Standard par Derek Jones), les bits
de padding sont en fait très rares.
Et, par ailleurs, pour moi le problème n'est pas tellement la prà ©sence
de bits de parité ou autre mais c'est surtout que j'ai une permanence
de la représentation des objets de valeur donnée, c'est à dire que,
par exemple, l'entier 421, dans un type donné et fixé, admette
toujours la même représentation tout au long de l'exécutio n du
programme en sorte que si je calcule la clé en me basant sur la
représentation, deux instances de 421 donnent la même clé.
Le 30/08/2013 16:48, Antoine Leca a écrit :
Définis « fin d'un membre » ?
Naïvement, ce qui commence à a+n où a est l'adresse du mem bre et n sa
taille.
Mmmm... Avec la méthode dont tu parles (écrire des octets à 0), au plus
tu vas pouvoir éradiquer les _octets_ de bourrage, c'est-à -dir e les
octets que le compilateur rajoute entre les membres pour différentes
raisons, de performance ou pour pouvoir avoir des accès correctement
alignés aux membres ou aux éléments d'un tableau de la st ructure.
Les _bits_ de remplissage sont pour moi un autre concept, celui de bits
sans signification sémantique mais qui font partie de la repré sentation
des objets en mémoire. On peut avoir des bits de parité, ou de s bits
imposé par le matériel, comme par exemple le cas (pas habituel en C,
mais qui peut exister avec d'autres langages) des valeur booléennes
stockées de manière comprimée à 8 par octet, quand o n les manipule de
manière individuelle il faut bien « gâcher » 7 bit p ar objet...
Tu veux dire alors que ces bits (parité, matériel) sont "incont rôlables" et
vont revenir même si on les éradique ?
Sinon, quelqu'un pourrait-il citer le passage de la norme qui montre que
les bits entre les membres d'une structure peuvent être modifié s Ã
n'importe quel accès au membre ? cf. ce que j'avais rapporté de mes
lectures sur clc mais qui ne donnaient aucune référence.
à ce que j'ai compris, il existe au plus trois types de
bits : bit de valeur, bit de signe et bit de padding. D'après ce que j'ai
lu (entre autres, les commentaires du Standard par Derek Jones), les bits
de padding sont en fait très rares.
Et, par ailleurs, pour moi le problème n'est pas tellement la prà ©sence
de bits de parité ou autre mais c'est surtout que j'ai une permanence
de la représentation des objets de valeur donnée, c'est à dire que,
par exemple, l'entier 421, dans un type donné et fixé, admette
toujours la même représentation tout au long de l'exécutio n du
programme en sorte que si je calcule la clé en me basant sur la
représentation, deux instances de 421 donnent la même clé.
Le 30/08/2013 16:48, Antoine Leca a écrit :Définis « fin d'un membre » ?
Naïvement, ce qui commence à a+n où a est l'adresse du mem bre et n sa
taille.Mmmm... Avec la méthode dont tu parles (écrire des octets à 0), au plus
tu vas pouvoir éradiquer les _octets_ de bourrage, c'est-à -dir e les
octets que le compilateur rajoute entre les membres pour différentes
raisons, de performance ou pour pouvoir avoir des accès correctement
alignés aux membres ou aux éléments d'un tableau de la st ructure.
Les _bits_ de remplissage sont pour moi un autre concept, celui de bits
sans signification sémantique mais qui font partie de la repré sentation
des objets en mémoire. On peut avoir des bits de parité, ou de s bits
imposé par le matériel, comme par exemple le cas (pas habituel en C,
mais qui peut exister avec d'autres langages) des valeur booléennes
stockées de manière comprimée à 8 par octet, quand o n les manipule de
manière individuelle il faut bien « gâcher » 7 bit p ar objet...
Tu veux dire alors que ces bits (parité, matériel) sont "incont rôlables" et
vont revenir même si on les éradique ?
Sinon, quelqu'un pourrait-il citer le passage de la norme qui montre que
les bits entre les membres d'une structure peuvent être modifié s Ã
n'importe quel accès au membre ? cf. ce que j'avais rapporté de mes
lectures sur clc mais qui ne donnaient aucune référence.
à ce que j'ai compris, il existe au plus trois types de
bits : bit de valeur, bit de signe et bit de padding. D'après ce que j'ai
lu (entre autres, les commentaires du Standard par Derek Jones), les bits
de padding sont en fait très rares.
Et, par ailleurs, pour moi le problème n'est pas tellement la prà ©sence
de bits de parité ou autre mais c'est surtout que j'ai une permanence
de la représentation des objets de valeur donnée, c'est à dire que,
par exemple, l'entier 421, dans un type donné et fixé, admette
toujours la même représentation tout au long de l'exécutio n du
programme en sorte que si je calcule la clé en me basant sur la
représentation, deux instances de 421 donnent la même clé.
Sinon, quelqu'un pourrait-il citer le passage de la norme qui montre que
les bits entre les membres d'une structure peuvent être modifiés à
n'importe quel accès au membre ? cf. ce que j'avais rapporté de mes
lectures sur clc mais qui ne donnaient aucune référence.
Sinon, quelqu'un pourrait-il citer le passage de la norme qui montre que
les bits entre les membres d'une structure peuvent être modifiés à
n'importe quel accès au membre ? cf. ce que j'avais rapporté de mes
lectures sur clc mais qui ne donnaient aucune référence.
Sinon, quelqu'un pourrait-il citer le passage de la norme qui montre que
les bits entre les membres d'une structure peuvent être modifiés à
n'importe quel accès au membre ? cf. ce que j'avais rapporté de mes
lectures sur clc mais qui ne donnaient aucune référence.
Lis attentivement le chapitre 6, en particulier 6.2.6.1
(dans C99) qui demarre par "The representations of all types are unspecified
except as stated in this subclause"...
tout le reste dit "unspecified" des qu'on parle de padding bits ou de
padding bytes.
Lis attentivement le chapitre 6, en particulier 6.2.6.1
(dans C99) qui demarre par "The representations of all types are unspecified
except as stated in this subclause"...
tout le reste dit "unspecified" des qu'on parle de padding bits ou de
padding bytes.
Lis attentivement le chapitre 6, en particulier 6.2.6.1
(dans C99) qui demarre par "The representations of all types are unspecified
except as stated in this subclause"...
tout le reste dit "unspecified" des qu'on parle de padding bits ou de
padding bytes.
