Union et son usage

Version imprimable

05/01/2012, 14h15
dafpp

Union et son usage
Bonjour,
je voudrai utiliser union pour séparer les élement d'un flux d'octets:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 union { unsigned char data[20]; struct { u_int8_t n1; u_int16_t n2; u_int32_t n3; ... } b; } a;
le soucis est dans ma structure, c'est que certaines informations dépassent la taille d'un int, ou d'un long, peu importe, c'est une donnée qui est trop longue pour le mettre dans un type primitif de nombre (int, double, ...). Donc je me tourne vers le char. Le soucis, c'est que lorsque je veux lire ma donee, je suis oblige de utiliser de la traiter comme une chaine de caractere, pas de soucis, mais pour la lire (avec printf par ex), etant donne que ce n'est qu'un simple lecture a partir d'une adresse, il me lit data, donc tout, alors que ce n'est pas que je souhaite.

Je sais très bien que je peux faire une copie en indiquant que je ne veux copier que x octets dans vers un espace allouer, mais j'aimerai eviter ça.

Donc n'y a t-il pas une autre alternative, comme un type plus ou moins neutre qui me permetrait de lire x octet, sans être obliger de passer vers une autre variable pour traiter l'information, car je ne veux pas modifier data.

Que me conseillez vous de faire ? ou n'est ce pas la bonne méthode pour résoudre ce type de problème ?

merci d'avance
05/01/2012, 14h28
hariman

Bonjour,

La fin d'une chaîne de caractère est marqué par le caractère '\0', donc le printf() t'affiche tout le contenu de data.
05/01/2012, 15h08
dafpp

oui, je le sais très bien ça,
ce que je voudrai c'est plutõt avoir un type comme int qui respecte la taille de son type, je veux dire par la que si la variable fait 2 octets, la lecture de la donnée ne fera que 2 octets.

je sais très bien comment faire avec un char, mais j'aimerai savoir s'il n'y a pas possibilité autrement.

car je voudrai decomposer mon flux d'octets grâce à union, mais j'aimerai savoir si c'est bien la bonne méthode, ou si il n'y a pas autrement,
05/01/2012, 15h30
hariman

Code:

for(i=0;i<x;putchar(data[i++]));
05/01/2012, 15h51
dafpp

oui je sais, mais ta méthod m'oblige a enregistrer x, mais je n'aurai pas qu'une seule donnée a traité, donc je vais pas enregistrer la taille. et de toute façon ça je sais trés bien le faire, mais je voudrai éviter de le faire.

mais j'ai trouner le problème, je pense que je serai obliger de passer par une autre variable pour traiter l'information char.
05/01/2012, 16h38
diogene

Attention à ce que les différents champs de la structure b ne sont pas forcément contigus en mémoire ce qui peut altérer la correspondance entre le contenu de data et les différents champs de b

salut !
je ne suis pas sûr d'avoir bien compris ta question.
Code:

1 2 3 4 5 6 7 8 9 10 11 union { unsigned char data[20]; struct { u_int8_t n1; u_int16_t n2; u_int32_t n3; ... } b; } a;
définit
Code:

1 2 |<--n1->|<------n2----->|<--------------n3------------->| |data[0]|data[1] data[2]|data[3] data[4] data[5] data[6]|
tu connais donc a priori le type des 7 premiers octets de data ?

A+

05/01/2012, 17h23
dafpp

Oui, mais si data fait plus de 100 octets, je ferai: char data[100].

mais si je veux récupérer 50 octets, avec une variable se trouvant dans la strucure, je n'ai que le chat a ma disposition. Donc n'y a til pas moyen de faire autrement.
05/01/2012, 21h46
Sve@r
Citation:

Envoyé par dafpp

Bonjour,

Salut

Ta dernière question est incompréhensible. Reprenons donc au début avec un peu plus de rigueur...
Citation:
Envoyé par dafpp

je voudrai utiliser union pour séparer les élement d'un flux d'octets:

Code:

1 2 3 4 5 6 7 8 9 10 11 union { unsigned char data[20]; struct { u_int8_t n1; u_int16_t n2; u_int32_t n3; ... } b; } a;

le soucis est dans ma structure, c'est que certaines informations dépassent la taille d'un int, ou d'un long, peu importe, c'est une donnée qui est trop longue pour le mettre dans un type primitif de nombre (int, double, ...). Donc je me tourne vers le char.
Non. Tu ne peux te tourner que vers le tableau de char !!!
De plus faut faire attention car dans une union tu ne peux pas lire le membre "y" si tu as rempli le membre "x". Cela conduit à un comportement indéterminé. Donc si tu remplis data tu n'as pas le droit d'aller taper dans n2.

Mais rien ne t'empêche de copier data dans une structure mappée pour ça
Code:

1 2 3 4 5 6 7 8 char data[20]; struct { u_int8_t n1; u_int16_t n2; u_int32_t n3; ... } b; memcpy(&b, data, 20);
Citation:

Envoyé par dafpp

Le soucis, c'est que lorsque je veux lire ma donee, je suis oblige de utiliser de la traiter comme une chaine de caractere,

Et pourquoi donc ? Ce n'en est pas une !!!

Citation:

Envoyé par dafpp

pas de soucis, mais pour la lire (avec printf par ex), etant donne que ce n'est qu'un simple lecture a partir d'une adresse, il me lit data, donc tout, alors que ce n'est pas que je souhaite.

Ben évidemment !!! Le traitement des chaines consiste à partir du début et continuer de case en case jusqu'à trouver un '\0'. Comme ta "chaine" n'en est pas une, cette façon de la traiter ne peut pas fonctionner !!! (et si ça fonctionne "parfois" cela n'est que de la chance).

Citation:

Envoyé par dafpp

Je sais très bien que je peux faire une copie en indiquant que je ne veux copier que x octets dans vers un espace allouer, mais j'aimerai eviter ça.

Donc n'y a t-il pas une autre alternative, comme un type plus ou moins neutre qui me permetrait de lire x octet, sans être obliger de passer vers une autre variable pour traiter l'information, car je ne veux pas modifier data.
Que me conseillez vous de faire ? ou n'est ce pas la bonne méthode pour résoudre ce type de problème ?

merci d'avance

Qu'est-ce qui t'empêche de lire "x" octets dans une boucle en partant de "n" ???
Code:

1 2 3 4 char data[20]; char *pt; for (i=0, pt=data + n; i < x /* x < (20 - n) */ ; i++, pt++) printf(isprint(*pt) ?"%c" :"%x", *pt);
05/01/2012, 23h46
anacharsis

@Sve@r

salut !

désolé de te contredire,

Citation:

De plus faut faire attention car dans une union tu ne peux pas lire le membre "y" si tu as rempli le membre "x". Cela conduit à un comportement indéterminé. Donc si tu remplis data tu n'as pas le droit d'aller taper dans n2.

le seul interêt des unions, c'est le fait que les champs se recouvrent. on peut parfaitement accéder à tous les champs, tout le temps. on a la garantie que tous les champs commencent à la même adresse (absence d'octet de remplissage avant un quelconque des champs de l'union).

A+
05/01/2012, 23h58
dafpp
Je vais tenter d'être un peu plus complet et concret dans mes exemple, et désolé pour l'incompréhension:

je veux décomposer une donnée de 32 octets.
je là lis, et je l'écris dans data.
et par la suite je ne veux plus toucher à data, je ne veux faire aucune modifications de données, je veux décomposer data qui a une structure fixe et qui contient plusieurs données différentes, à des emplacements différents.
Ma solution est l'union, avec une structure décomposant toutes les données de data à certains emplacements que je veux récupérer:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 union { unsigned char data [32]; struct { -- type: 112; u_int8_t taille2; int separateur: 8; int taille: 32; int taille3: 8; -- separateur: 52; int nbelement: 32; } }
Donc je me retrouve avec des types inconnu, je ne sais pas quoi mettre aux emplacements de "--" sans me retrouver avec un char.
C'est pas que ça me gène le char, car il n'y a pas d'int possible (je pourrai faire long double, mais c'est pas jolie - quoi que - mais la donnée est plus grande que long double complex ? (le plus grand type que je connaisse) ) c'est juste que ça m'oblige a copier la donnée pour la récupérer correctement.

j'en profite pour savoir si il y a une vrai différence entre u_int8_t et faire int x: 8; ? Qu'est ce qui est mieux pour être de súr de manipuler des donnée à taille souhaité ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
typedef union
{
			unsigned char data[32];
			struct{
				char t [14];
				unsigned char taille2;
				unsigned char separateur;
				int taille;
				unsigned char taille3;
				unsigned char separateur2[7];//je pense à une typo 56 au lieu de 52
				int nbelement;
			}z; 
} parser_t;
.
.
	printf("size=%d\n", sizeof(parser_t));

si ton compilateur te donne 32, tu ne peux pas avoir de padding et toutes tes données sont exploitables.

A+

06/01/2012, 08h45
valefor

Supposons ton problème de structure résolu... Ce qui à mon avis n'est pas encore le cas (à cause de l'alignement notamment qui pourrait être résolu avec un attribut packed par exple).

Est-ce que ta donnée de 112 bit (14 octets) représente un int, un double, autre choses ? Si elle représente un nombre, est-ce que tu as prévu un codage spécial ? Par exemple si c'est un entier, il faut que tu ais défini quelque part une structure qui te permette de stoker un entier sur 14 bit, dotée de fonctions te permettant de le transformer en chaîne, de faire des opérations etc. Il existe des libraires qui font ce genre de choses :gnu GMP par exemple. Tu as sur wikipedia un exemple de comment cela marche.

Désolé pour la confusion si ce deuxième point n'a aucun lieu avec ta question.
06/01/2012, 10h47
Bktero

Citation:

Envoyé par anacharsis

salut !

désolé de te contredire,le seul interêt des unions, c'est le fait que les champs se recouvrent. on peut parfaitement accéder à tous les champs, tout le temps. on a la garantie que tous les champs commencent à la même adresse (absence d'octet de remplissage avant un quelconque des champs de l'union).

A+

Citation:

Envoyé par diogene

Attention à ce que les différents champs de la structure b ne sont pas forcément contigus en mémoire ce qui peut altérer la correspondance entre le contenu de data et les différents champs de b

Ces 2 phrases ne sont pas en contradiction ? :oops:
06/01/2012, 11h06
anacharsis

@Bktero

salut !
non, il n'y a pas contradiction entre ces deux phrases :
--- diogène parle de struct
--- moi d'union

A+
06/01/2012, 11h27
diogene

On a également le même problème sur les champs de bits qui ne sont pas forcément contigus : Si un champ de bits ne remplit pas complètement une unité adressable, le champ de bits suivant peut continuer le remplissage de cette unité ou commencer à l'unité adressable suivante; cela dépend de l'implémentation. (et la question est d'actualité à cause du " -- separateur: 52;" avec une unité adressable de 8 bits)

Passer par une union et/ou des champs de bits n'est sans doute pas une très bonne idée.
06/01/2012, 11h51
anacharsis

@dafpp

Citation:

... un type plus ou moins neutre qui me permetrait de lire x octet, sans être obliger de passer vers une autre variable pour traiter l'information, car je ne veux pas modifier data.

je crois que char tab[7] est un type tout à fait neutre. c'est un tableau de 7 octets, pas une chaîne de caractères; tu as le droit de l'interpréter comme une chaîne si un de ces octets est 0, mais rien ne t'y oblige. c'est à toi de décider !
par contre comme tu ne veux pas modifier data, tu ne peux pas modifier ce tableau, ni aucune des champs de la struct (elle recouvre data).

A+
06/01/2012, 12h14
dafpp

je fais dans le sens inverse:

@anacharsis:
Je ne veux modifier aucune donnée que ce soit dans union ou dans la struct.
je copie une fois la donnée dans data, et puis basta.
Le char est donc plus neutre pour ce que je veux faire ?

@diogene:
Mais une union pose bien les éléments à la suite ? Si le nombre d'octet, chez moi, est le même que data et dans la structure, il ne devrait pas avoir de problème ? (pas d'espaces de mémoires non contigus), je me trompe ?

@valefor
Non heureusement ma donnée de 112 octets ne représente pas entier, heureusement, mais tu fais bien de le dire.

@anacharsis:
Oui d'accord, c'est pour ça, je me suis bien trompé pour 52, c'est bien 56.
Mais pourquoi mettre mes int en char ?
Tout les int que j'ai mis sont des entiers à traités, tout le reste sont des chaines de caractères que je souhaite récupérer.
Un char s'écrit bien de la même façon qu'un int ? (en binaire) - ou je confonds totalement.

Donc il n'y a pas possibilité d'éviter des char de ce que je vois.
car le char m'oblige à connaitre sa taille pour pouvoir récupérer cette dernière, et moi j'aimerai l'éviter.

Je ne sais pas si ça peu aider pour la résolution du problème, mais je tente d'apprendre un lire un type de fichier. J'en ai sorti une règle, qui se définit par des bloc de donnée fixe (comme data qui fait 32 octets), et ce bloc de donnée se divise encore en plusieurs partit qui correspond chacun a des donnée différente.
Donc les donnée sont des entiers - little endian (il me faudra juste convertir la donnée) - et tout le reste, sont des données de type caractère.
J'en profite de nouveau pour reposer ma question qui est:
j'en profite pour savoir si il y a une vrai différence entre u_int8_t et faire int x: 8; ? Qu'est ce qui est mieux pour être de súr de manipuler des donnée à taille souhaité ? -- Je ne pense avoir eu une réponse.

- merci beaucoup pour vos réponses.
06/01/2012, 13h42
Bktero

Citation:

Envoyé par anacharsis

salut !
non, il n'y a pas contradiction entre ces deux phrases :
--- diogène parle de struct
--- moi d'union

A+

Dans le cas exposé par dafpp, il a une union entre un tableau et une structure. Si les champs de la structure ne sont pas continus en mémoire, alors le tableau et la structure ne sont pas forcément superposés. Sinon, dans ta phrase, il faut comprendre que le premier champ de la structure est superposé au tableau (même adresse de début pour les 2) ?
06/01/2012, 16h31
anacharsis

@Bktero
oui ! c'est garanti par la définition du langage : dans une union tous les champs ont la même adresse (celle de l'union) , et dans une structure le premier champ a l'adresse de la structure.

@dafpp
oui ! c'est aussi une définition du langage un champ de bits comme

Code:

int x:8;

n'a pas d'adresse.
je me doutais que tu explorais des fichiers mal connus (je viens tout juste de faire çà sur des .VOB).

A+
06/01/2012, 19h26
dafpp

Pas d'adresse, tu veux dire quoi par là ? j'arrive à lire la donnée sans difficultée.
06/01/2012, 21h26
Sve@r
Citation:

Envoyé par anacharsis

salut !

désolé de te contredire,

Moi pareil :mrgreen:

Citation:

Envoyé par anacharsis

le seul interêt des unions, c'est le fait que les champs se recouvrent.

Jusque là je suis d'accord.

Citation:

Envoyé par anacharsis

on a la garantie que tous les champs commencent à la même adresse (absence d'octet de remplissage avant un quelconque des champs de l'union).

Là pareil

Citation:

Envoyé par anacharsis

on peut parfaitement accéder à tous les champs, tout le temps.

Là (désolé de te contredire) mais non. Dans un union (comme cet exemple)
Code:

1 2 3 4 union { int x; long y; } toto;
Tu peux remplir toto.x puis lire toto.x. Puis remplir toto.y puis lire toto.y. Mais tu ne peux pas remplir toto.x et lire toto.y, cela amène un comportement non garanti donc indéterminé...
06/01/2012, 22h02
dafpp

En tant que tel on peut, le résultat sera juste faux.

Je n'ai toujours pas eu mes réponses !! :cry::cry:
06/01/2012, 22h18
Sve@r

Citation:

Envoyé par dafpp

En tant que tel on peut, le résultat sera juste faux.

Non même pas. Oui si on le fait quand-même le résultat sera faux mais on n'a pas le droit de lire le membre de l'union qui n'est pas le dernier a avoir été écrit (http://www.developpez.net/forums/d70...s/#post4129693; http://www.developpez.net/forums/d83...s/#post4757449).
Tout comme aller taper dans tab[5] quand tab est défini comme char[5]. On peut écrire l'instruction, on a 99,9% de chances que ça ne plante pas et avoir un résultat mais c'est interdit par la norme.
Il ne faut pas confondre "taper un code qui compile" et "avoir le droit de le taper"...

Citation:

Envoyé par dafpp

Je n'ai toujours pas eu mes réponses !!

Bah tu en as eu pas mal. On t'a donné des pistes et des billes...
06/01/2012, 22h23
dafpp

C'est bien vrai, mais je pensais qu'il y avait d'autre solution, mais l'union est pas vraiment bien pour faire ce que je souhaite.
Je vais tenter de trouver un stratagème pour mes histoires de char.

tu devrais insister, car ça marche

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include <stdio.h>
typedef union{
	unsigned char a;
	unsigned short b;
	unsigned int c;
} uni_t;
void dump(unsigned char * p){//écrit les 4 octets de l'union en hexa
	int i;
	for(i = 0; i < 4; i++)
		printf("%02X ", p[i]);
	puts("");
}
void main(void){
	uni_t u;
	printf("u size=%d address=%p\n", sizeof(u), &u);
	printf("a size=%d address=%p\n", sizeof(u.a), &u.a);
	printf("b size=%d address=%p\n", sizeof(u.b), &u.b);
	printf("c size=%d address=%p\n", sizeof(u.c), &u.c);
	puts("FF FF FF FF dans u en écrivant c");
	u.c = -1;
	dump(&u);
	puts("00 00 FF FF dans u en ecrivant b");
	u.b = 0;
	dump(&u);
	puts("FF 00 FF FF dans u en ecrivant a");
	u.a = -1;
	dump(&u.c);
	puts("remarquez que j'ai lu u.c alors que je viens d'ecrire u.a");
}

il suffit juste de savoir ce qu'on veut faire.

A+

07/01/2012, 09h15
diogene

Sur le sujet de lecture/ecriture des membres d'une union, consultez la discussion suivante Recopier 4 char dans un float

Les solutions proposées dans cette discussion peuvent d'ailleurs inspirer dafpp

Je vois un peu plus clair, mais sans doute parce que je ne code pas, et j'essaie d’abord de visualiser la chose, mais je ne vois pas comment je vais échapper aux char et de devoir enregistrer la taille de la chaine, à moins de faire - car les int me permettait de lire de traiter les 4-2 octets sans soucis:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 struct { union { char data[32]; struct { char d1[20]; char d2[2]; ... } k; } motif; int * tab; //tableau des tailles de chaque types de "struct union struct", étant donné que je ne peux pas assurer d'avoir un \o dans les parties fixes des char, et que je ne suis pas sûr que ça n'arrivera qu'un fois ce problèmes. }

07/01/2012, 12h24
souviron34

Citation:

Envoyé par Sve@r

Non même pas. Oui si on le fait quand-même le résultat sera faux mais on n'a pas le droit de lire le membre de l'union qui n'est pas le dernier a avoir été écrit (http://www.developpez.net/forums/d70...s/#post4129693; http://www.developpez.net/forums/d83...s/#post4757449).

J'avoue que je ne savais pas..

Cependant, je trouve la formulation mauvaise :

puisque les variables démarrent à la même adresse, c'est simplement que les -définis par le type de x - n bytes (ou bits) sont écrits.

Lire / se référer à une variable de type <= au type de x est donc possible : les bits ont été assignés (même si la valeur est incohrente)

Et je dirais plus : si la valeur la plus grande de l'union a été assignée une fois, ou l'union a été créée via un calloc (et pas un malloc), cela devrait marcher, même si les valeurs sont incohérentes, tous les bits ont été assignés...

Cela revient un peu à l'exemple que je donnais dans l'autre discussion à propos de l'instruction EQUIVALLENCE en Fortran.....

Me trompe-je ???

@dafpp

deux point dans ton dernier code.

Code:

int * tab; //tableau des tailles de chaque types de "struct union struct", étant donné que je ne peux pas assurer d'avoir un \o dans les parties fixes des char, et que je ne suis pas sûr que ça n'arrivera qu'un fois ce problèmes.

ne déclare pas un tableau, seulement un pointeur.
ce tableau ne serait pas très utile dans l'état actuel du programme. tu n'as pas besoin de te souvenir des tailles de d1, d2, ... car le compilateur s'en souvient
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 #include <stdio.h> struct stru_t { union uni_t { char data[32]; struct stru_k { char d1[20]; char d2[2]; char d3[10]; } k; } motif; int * tab; //tableau des tailles de chaque types de "struct union struct", étant donné que je ne peux pas assurer d'avoir un \o dans les parties fixes des char, et que je ne suis pas sûr que ça n'arrivera qu'un fois ce problèmes. } s = { { {'a', 'z', 'e', 'r', 't', 'y', 'u', 'i', 'o', 'p', 'q', 's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'm', 'w', 'x', 'c', 'v', 'b', 'n', '1', '2', '3', '4', '5', '6' } }, { NULL } }; void main(void){ int i; for (i = 0; i < sizeof(s.motif.k.d1); i++) putch(s.motif.k.d1[i]); puts(""); for (i = 0; i < sizeof(s.motif.k.d2); i++) putch(s.motif.k.d2[i]); puts(""); }
A+

07/01/2012, 14h20
dafpp

Oui tu fais bien de le préciser, mais vu que c'était une déclaration, je ne pouvais pas remplir le tableau directment, donc je me suis arreté à là.

@ tous ceux qui ne veulent pas lire un champ qui n'est pas le dernier écrit

extrait du draft de C99 dont je dispose.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256
8 EXAMPLE 3 The following is a valid fragment:
union
{
   struct 
   {
      int alltypes;
   } n;
   struct 
  {
     int type;
     int intnode;
   } ni;
   struct 
  {
     int type;
     double doublenode;
   } nf;
} u;

u.nf.type = 1;
u.nf.doublenode = 3.14;
/* ... */
if (u.n.alltypes == 1)
if (sin(u.nf.doublenode) == 0.0)
/* ... */

A+

07/01/2012, 14h49
souviron34
je ne vois pas comment cela peut être implanté à part avoir des vraies variables différentes, présentées comme une union mais étant réellement une structure..

Et dans ce cas on perd un des grands avantages de l'union qui est le gain de place mémoire..

pour n'en garder qu'un qui est la flexibilité d'écriture..

De mon point de vue c'est un retour en arrière et une perte sèche..

Note: :oops: ici c'est bien une structure... je ne vois pas pourquoi tu as cité ça, c'est tellement largement utilisé que ça ne rentre pas dans le cas du débat, si ??? et ça ne date pas de C99... cela a toujours été possible..

Par contre, si l'union reste ce qu'elle est, alors ce me semble ma remarque du post précédent reste valable
Code:

1 2 3 4 5 6 7 8 9 10 typedef union _pu { char *s ; char c ; int i ; double d ; } u ; u myu ; myu.i = 0 ;
dans ce cas, myu.c devrait être égal à 0, et myu.s à NULL (si NULL est bien défini comme 0x0), non ?
07/01/2012, 15h09
Jean-Marc.Bourguet

Citation:

Envoyé par diogene

Sur le sujet de lecture/ecriture des membres d'une union, consultez la discussion suivante Recopier 4 char dans un float

J'allais répéter mais je vois que j'ai déjà tout dit dans cette discussion.
07/01/2012, 15h19
Jean-Marc.Bourguet
Citation:
Envoyé par souviron34

Code:

1 2 3 4 5 6 7 8 9 10 typedef union _pu { char *s ; char c ; int i ; double d ; } u ; u myu ; myu.i = 0 ;

dans ce cas, myu.c devrait être égal à 0
Sauf dans le cas tordu où les int ont des bits de padding. J'ai déjà entendu parler d'architectures anciennes où c'est le cas, mais on ne m'a jamais confirmé qu'il y a jamais eu une implémentation du C pour ces machines.

Citation:

et myu.s à NULL (si NULL est bien défini comme 0x0), non?

La constante entière 0, éventuellement castée en void*, est utilisée comme valeur pour NULL, mais la représentation physique peut être différente (et c'est un peu plus courant que le cas précédant, j'ai déjà entendu des rumeurs d'implémentations l'ayant fait). En prime, rien ne garanti que sizeof(myu.s) == sizeof(myu.i) (p.e. les implémentations sur 64 bits sont généralement des pointeurs sur 64 bits et des entiers sur 32).

C'est comme pour les flottants, la valeur entière 0 -- et toutes les autres dans le cas des flottants -- peut être utilisées dans les contextes où il faut un flottant, la représentation utilisée ne sera pas nécessairement la même que celle de l'entier 0. Donc même si sizeof(myu.d) == sizeof(myu.i) (ce qui est rare), tu ne peux rien déduire de la valeur de myu.d.
07/01/2012, 15h28
souviron34

ok.

J'avais bien conscience pour les flottants, mais je pensais que pour les entiers, avec 0 ça marchait..

'fin bref, en général dans les unions on siat quel membre on utilise..

Sauf pour le cas du thread, auquel cas sans doute un champ de bits ou une analyse de bits convient miuex, je pense..

Merci des liens, je m'endormirais moins bête ce soir :aie: (quoique..;))

Citation:
Envoyé par anacharsis
extrait du draft de C99 dont je dispose.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256 8 EXAMPLE 3 The following is a valid fragment: union { struct { int alltypes; } n; struct { int type; int intnode; } ni; struct { int type; double doublenode; } nf; } u; u.nf.type = 1; u.nf.doublenode = 3.14; /* ... */ if (u.n.alltypes == 1) if (sin(u.nf.doublenode) == 0.0) /* ... */
A+
Ce type de code constitue une exception, comme explicité ici, car les structures partagent une structure initiale commune:

Citation:

Envoyé par n1256 §6.5.2.3

One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.

C'est le seul cas prévu par la norme où il est possible d'accéder à la donnée stockée dans une union par un champ différent de celui utiliser pour initialiser cette dernière. Cette exception est toutefois limitée à la séquence commune des deux structures.

Avec mes meilleures salutations

Thierry

09/01/2012, 15h33
souviron34

Citation:

Envoyé par Thierry Chappuis

Ce type de code constitue une exception, comme explicité ici, car les structures partagent une structure initiale commune:

exception, exception... t'y vas fort..:D

Toute la programmation événementielle en C repose dessus : tout le code de X11 (depuis 1984)...

Et dès q'on veut faire des fonctions enregistrées, (style callbacks) on utilise ce genre de mécanismes et de recouvrement...
09/01/2012, 16h15
Jean-Marc.Bourguet

Citation:

Envoyé par Thierry Chappuis

C'est le seul cas prévu par la norme où il est possible d'accéder à la donnée stockée dans une union par un champ différent de celui utiliser pour initialiser cette dernière. Cette exception est toutefois limitée à la séquence commune des deux structures.

C'est dépendant de l'implémentation et a le même effet qu'un memcpy. Voir
http://www.open-std.org/JTC1/SC22/WG...ocs/dr_283.htm pour une clarification du texte de C99.
10/01/2012, 04h27
dafpp

Bon j'ai rusé j'ai mis des '\0' en fin de chaine, je ne peux pas le faire pour toutes, mais c'est déjà ça, je ferai une copie d'octets à taille fixe pour gérer les parties où je ne peux pas faire comme j'ai dis juste avant.

Merci à tous.

Fuseau horaire GMT +2. Il est actuellement 16h19.