Discussion :

[dafpp]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[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,

[hariman]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(i=0;i<x;putchar(data[i++]));

[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.

[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

[anacharsis]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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+

[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.

[Sve@r]

Bonjour,

Salut

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

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

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

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 c :

Sélectionner tout - Visualiser dans une fenêtre à part

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);

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 !!!

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).

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 c :

Sélectionner tout - Visualiser dans une fenêtre à part

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);

[anacharsis]

salut !

désolé de te contredire,

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+

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é ?

[anacharsis]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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+

[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.

[Bktero]

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+

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 ?

[anacharsis]

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

A+

[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.

[anacharsis]

... 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+

[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.

[Bktero]

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) ?

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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+