Tableau d'element hexa tronqué

Bonjour,

je dois faire passer un message a une fonction de unpacking. J'essaye donc de passer le tableau de char suivant (6 octets):

Code:

---

const unsigned char msg2[]= {0x02,0x00,0xC0,0x01,0x45,0x85};

---

La fonction d'unpacking est correcte, cependant il semble que mon tableau soit tronqué dès le second octet. Je suppose que l'octet 0x00 (cf. deuxieme element du tableau) est considérée comme un caractere de terminaison '\0'.

Savez vous comment remedier a ce probleme?

Merci d'avance de votre aide,

Voi,

Que la fonction de unpacking ne considère pas le paramètre passé comme une chaîne à terminaison 0.

Passer l'adresse du tableau, + le nombre de valeurs qu'il contient. :)

Merci du conseil, mais le message est tronqué avant l'unpacking lors de l execution.
Je passe bien l adresse du tableau a ma fonction, et la taille a unpacker est bien un parametre d entrée... plus generalement je ne pense pas que mon pb soit lié a la fonction d unpacking, mais a la formation de mon message. meme avec un printf("%s" ,msg2); l affichage est tronqué.

est il correct de créer un data set tel que jai fait?

Je vous dit bonne nuit, jy donnerai plus de temps demain.

Merci

Salut,

Citation:

---

Envoyé par droggo

Voi,

Que la fonction de unpacking ne considère pas le paramètre passé comme une chaîne à terminaison 0.

Passer l'adresse du tableau, + le nombre de valeurs qu'il contient. :)

---

Voire, mieux...

Selon que le nombre d'éléments du tableau soit connu ou non à la compilation, utiliser la classe boost::array ou la classe std::vector pour maintenir les différents caractères...

La classe boost::array permet de déclarer des tableaux de taille fixe mais qui connaissent leur taille, et la classe vector, fournie par le standard dans l'espace de noms std permet de déclarer des tableaux dont la taille est gérée dynamiquement et qui connaissent leur taille...

Cela permet d'éviter une mauvaise interprétation des données qui serait due au fait de considérer ton tableau de caractères comme... une chaine de caractères, dont le dernier caractère utile est suivi par le caractère nul (0x00 ou '\0').

De plus, je me méfie énormément des déclarations de tableaux telles que tu la présente, car, je me demande toujours si ton tableau constant n'est pas une variable globale...

Et je te rappelle volontiers que les variables globales, c'est mal ;)

Merci du conseil,

Jai pour contrainte de passer un

Code:

---

const unsigned *char

---

a ma fonction d unpacking d ou mon array.

Deux choses en vitesse:

la fonction

Code:

---

printf("%s", msg2);

---

est non seulement une fonction issue du C (donc à éviter autant que possible), mais, en plus, provoque l'affichage... d'une chaine de caractères "C style" (un tableau de caractères dont le dernier caractère utile est suivi par '\0')...

Il est donc normal que le tableau *semble* tronqué après le premier caractère nul rencontré dans le tableau ;)

Si, dans la fonction, tu vérifie les valeurs des caractères aux indices 2, 3, 4 et 5 (selon ton exemple) tu verra qu'elles correspondent bel et bien aux valeurs définies ;)

La deuxième chose est que je souhaiterais que tu m'en dise plus sur la contrainte que tu as de passer un const unsigned char* à ta fonction unpacking...

Est-ce spécifiquement et clairement indiqué dans les specs :question:
La fonction unpacking est-elle issue d'une bibliothèque tierce pour laquelle tu n'a pas acces au code source :question:

Si tu n'est pas dans un de ces deux cas, tu peux me croire sur parole (il est trop tard pour que je me lance dans une prose qui justifiera ce conseil), tu as très largement intérêt à préférer l'utilisation des classes dont j'ai parlé plus haut...

Car, les classes dont je te parle sont réellement des tableau d'éléments contigus, et permettent à tout moment de récupérer un tableau "C style" ;)

De plus, tu ne m'a pas confirmé, ni infirmé, le fait que ce tableau servait de variable globale...

Si c'est le cas, tu n'as normalement même pas à le passer en paramètre à une fonction: par définition même, une variable globale est accessible de partout ;)... Et c'est bien la raison pour laquelle il est préférable de les éviter ;)

Merci pour tes réponses koala01.

Je me dois à de plus amples détails.

Je viens de Java :cry: et je decouvre donc les subtilité du CPP (bien qu ayant fait du C a l'école).

D'abord je suis totalement d'accord avec toi pour utiliser un autre type de donnée pour créer mon data stream.
Mais, je suis dans un contexte de test ou je cherche en fait à stimuler une fonction qui a pour paramètre d'entrée :

Code:

---

unpack(const unsigned char *ptr, unsigned int size)

---

Je stimule la fonction de la facon suivante

Code:

---

1 2 3 4 5

char msg[]= {0x02,0x04,0xC0,0x00,0x45,0x85,0x60,0x3C,0x48,0x1A,0x71,0x03,0xFC,0x06,0xA0,0x8F,0x60,0xAC,0x80,'\0'};   char *p=new char[]; strcpy (p,msg); int r = unpack(reinterpret_cast<unsigned char*>(p), 19);

---

D'oú ma contrainte, je ne suis pas responsable du code écrit mais je dois la tester. Et il semble que la seule facon (selon moi) de stimuler la fonction d'unpacking soit avec un paramètre d'entrée de type

Code:

---

const unsigned char msg2[]= {0x02,0x00,0xC0,0x01,0x45,0x85};

---

Le depaquetage est correcte tant que l'octet 0x00 ne soit pas au milieu du message, je peux l'observer dans le debugger (Visual studio 6), d'ailleurs la representation de mon message (visualisation de mon message en ascii) est egalement tronqué dans le debugger VS6, non seulement avec "printf".

Dans mon contexte de test, je ne cherche donc pas a utiliser le tableau comme une variable globale. Je dois juste respecter la signature de la fonction à tester.

Par ailleur j'ai vu des exemples de code C ou CPP sur le net avec des tableaux d'hexa afin de véhiculer des data stream tel que je l'utilise, donc il ne semble pas que ce soit une pratique "éxotique".

Il y aurait t'il un autre manière de stimuler ma fonction en respectant sa spec? Ou bien de faire comprendre au compilateur que le 0x00 n'est pas la terminaison de tableau '\0' ?

Grand merci pour vos réponses et conseils 8-)

Cao,

Citation:

---

Envoyé par 0xygene

Il y aurait t'il un autre manière de stimuler ma fonction en respectant sa spec? Ou bien de faire comprendre au compilateur que le 0x00 n'est pas la terminaison de tableau '\0' ?

---

Non. :(

Ta fonction demande une chaîne de style C, et le 0 marque la fin pour toutes les fonctions les utilisant.

Bon si ce n'est pas possible... c'est toujours bon a savoir.

Il ne reste plus qu a générer des messages sans l'octet 0x00 :cry: pour stimuler mes tests...

Merci de la réponse.

Bon, j'ai compris le fait que tu présente le message comme un const unsigned char[]...

Par contre, j'aimerais que tu me précise ce qu'indique les specs concernant l'évaluation de la fin du message passé en paramètre...

En effet, le deuxième code que tu présente m'interpelle de par la présence du '\0' en tant que dernier caractère :aie:

Soit, tu l'a mis parce que c'est une obligation due aux spécifications, et, dans ce cas, il ne devrait pas y avoir de caractère nul dans le corps du message, ce qui fait que tester l'appel de la fonction avec un message contenant un caractère nul ailleurs qu'en fin de message tend à pousser la fonction à la faute, soit tu l'a placé "par hasard", ou, plus vraisemblablement, par erreur, afin de pouvoir utiliser strcpy (qui est, elle aussi, une fonction que je déconseille d'utiliser en C++)...

Ceci dit, le nom de la fonction (unpack), son prototype (const unsigned char[], unsigned int) et le fait que tu manipule des données hexadécimales sont de nature à me faire penser que cette fonction est sensée manipuler un tableau de caractères en ne le considérant pas comme une chaine de caractères "affichable" mais comme des données brutes.

dans ce cas, un caractère nul présent à l'intérieur du message pourrait s'envisager dans le sens où il serait en définitive considéré comme une partie d'une donnée de taille plus importante (la donnée pourrait ressembler à 0x0200C0, par exemple)

Et dans ce cas, si le fait de passer le tableau de caractères {0x02,0x00,0xC0,0x01,0x45,0x85} fait partir la fonction en vrille, c'est que la logique de cette fonction n'a pas été respectée :aie:

Cela implique qu'il faille... vérifier et modifier la fonction unpack :aie:

Enfin, je te l'ai sans doute bien fait comprendre, je suis relativement opposé à l'utilisation des tableaux de caractères C style...

Or, je subodore, de par tes explications, que le message est en réalité récupéré depuis "ailleurs", sous une forme qui est susceptible de te donner non seulement un pointeur sur le premier caractère mais également le nombre de caractères dont le message est composé...

il serait donc tout à fait possible d'utiliser la classe vector dans ton test, sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

/* soit msg est le pointeur sur le premier caractère  * et length la taille du message  */ /* transformons le message en un vecteur de caractères,  * de manière à être sur de ne pas le considérer comme une chaine  * de caractères, mais aussi de manière à être sur de considérer  * les différents caractères comme des unsigned char  */ std::vector<unsigned char> tab(msg,msg+lengt); /* tu peux "t'amuser" avec tab ici */ /* pour appeler la fonction unpack, cela se fait sous la forme de  */ int result= unpack(&tab[0],tab.size());

---

NOTA: l'avantage de la constance, c'est qu'elle peut être ajoutée à peu près n'importe quand...

Quasi toutes les fonctions demandant un argument constant se satisfont très bien du fait que tu leur passe une variable non constante à la base ;)

L'inverse n'est par contre pas vrai.

@ koala01,

Citation:

---

Ceci dit, le nom de la fonction (unpack), son prototype (const unsigned char[], unsigned int) et le fait que tu manipule des données hexadécimales sont de nature à me faire penser que cette fonction est sensée manipuler un tableau de caractères en ne le considérant pas comme une chaine de caractères "affichable" mais comme des données brutes.

---

Exatement, ta reformulation est plus claire que ma formulation ;)
Tu as bien compris mon cas de figure.

Citation:

---

En effet, le deuxième code que tu présente m'interpelle de par la présence du '\0' en tant que dernier caractère

---

C'est une erreur, ou du moins un de mes nombreux essais, je veux en fait faire un message de format {0x02,0x00,0xC0,0x01,0x45,0x85} sans le '\0' final.

J'ai peu de doute quand à la quailté de la fonction unpack, je pense qu'elle unpack tout a fait correctement une donnée brute de type 0xab0034, je pense que le problème vient de mon manque d experience du cpp, et mon array d´hexa ne semble pas approprié pour ce cas la.

Merci de l'astuce avec vector, je vais essayer et te faire un retour plus tard.

Merci beaucoup de votre aide et de votre temps .:king:

Citation:

---

Envoyé par 0xygene

Exatement, ta reformulation est plus claire que ma formulation ;)
Tu as bien compris mon cas de figure.

---

J'attirerai donc juste ton attention sur le fait qu'il ne faut en aucun cas faire la moindre tentative d'affichage de données brutes, que ce soit avec cout ou avec les fonctions issues du C...

En effet, tu ne peux considérer chaque caractère que comme... un caractère :P

De ce fait, comme tous les caractères dont la valeur hexadécimal est inférieure à 0x20 (32 en décimal) sont des caractères "non affichables" dans la table ASCII, ou peu s'en faut, tu as presque de la chance que le premier caractère dans le cas soit un caractère nul, qui est considéré comme la fin de la chaine :aie:

Parce que si tu étais tombé sur autre chose, tu aurais eu des surprises sans nom ;)

Citation:

---

Envoyé par 0xygene

Je stimule la fonction de la facon suivante

Code:

---

1 2 3 4 5

char msg[]= {0x02,0x04,0xC0,0x00,0x45,0x85,0x60,0x3C,0x48,0x1A,0x71,0x03,0xFC,0x06,0xA0,0x8F,0x60,0xAC,0x80,'\0'};   char *p=new char[]; strcpy (p,msg); int r = unpack(reinterpret_cast<unsigned char*>(p), 19);

---

D'oú ma contrainte, je ne suis pas responsable du code écrit mais je dois la tester. Et il semble que la seule facon (selon moi) de stimuler la fonction d'unpacking soit avec un paramètre d'entrée de type

Code:

---

const unsigned char msg2[]= {0x02,0x00,0xC0,0x01,0x45,0x85};

---

Le depaquetage est correcte tant que l'octet 0x00 ne soit pas au milieu du message, je peux l'observer dans le debugger (Visual studio 6), d'ailleurs la representation de mon message (visualisation de mon message en ascii) est egalement tronqué dans le debugger VS6, non seulement avec "printf".

---

J'ignore si le comportement de la fonction unpack est correct ou non. Par contre je peux déjà dire que l'appel à cette fonction est incorrect.

En effet strcpy() ne va copier que les caractères jusqu'au premier 0x00 rencontré, ainsi seul les 4 premiers bytes de msg seront effectivement copiés dans p, derrière il y a n'importe quoi.

Je comprends tout à fait la raison qui t'oblige à utiliser des tableau "C" et non des vector dans ton ode. Par contre je ne comprends pas du tout pourquoi tu cherches à copier msg dans p et pourquoi tu caste p.
Le code suivant ne convient-il pas ?

Code:

---

1 2 3

unsigned char msg[]= {0x02,0x04,0xC0,0x00,0x45,0x85,0x60,0x3C,0x48,0x1A,0x71,0x03,0xFC,0x06,0xA0,0x8F,0x60,0xAC,0x80};   int r = unpack(msg, sizeof msg);

---

Citation:

---

Envoyé par gl

J'ignore si le comportement de la fonction unpack est correct ou non. Par contre je peux déjà dire que l'appel à cette fonction est incorrect.

En effet strcpy() ne va copier que les caractères jusqu'au premier 0x00 rencontré, ainsi seul les 4 premiers bytes de msg seront effectivement copiés dans p, derrière il y a n'importe quoi.

Je comprends tout à fait la raison qui t'oblige à utiliser des tableau "C" et non des vector dans ton ode. Par contre je ne comprends pas du tout pourquoi tu cherches à copier msg dans p et pourquoi tu caste p.
Le code suivant ne convient-il pas ?

Code:

---

1 2 3

unsigned char msg[]= {0x02,0x04,0xC0,0x00,0x45,0x85,0x60,0x3C,0x48,0x1A,0x71,0x03,0xFC,0x06,0xA0,0x8F,0x60,0xAC,0x80};   int r = unpack(msg, sizeof msg);

---

---

Ce qui justifie, la méthode que j'ai proposée ;)

Ceci dit, nous pourrions aussi envisager un fonctionnement proche de

Code:

---

1 2 3 4 5 6 7 8 9 10

/* déclarons notre tableau de données brutes */ std::vector<unsigned char> tab; /* tant que l'on a une donnée qui arrive */ while(reception_d_un_char) { /* nous l'introduisons dans le tableau */ tab.push_back(le_char_recu); } /* une fois toutes les données reçues, nous appelons la fonction unpack */ int result = unpack(&tab[0], tab.size());

---

Citation:

---

Envoyé par koala01

Ceci dit, nous pourrions aussi envisager un fonctionnement proche de

Code:

---

1 2 3 4 5 6 7 8 9 10

/* déclarons notre tableau de données brutes */ std::vector<unsigned char> tab; /* tant que l'on a une donnée qui arrive */ while(reception_d_un_char) { /* nous l'introduisons dans le tableau */ tab.push_back(le_char_recu); } /* une fois toutes les données reçues, nous appelons la fonction unpack */ int result = unpack(&tab[0], tab.size());

---

---

S'il lui est possible de passer par des vector, c'est effectivement largement préférable. Mais j'ai cru comprendre qu'il ne le pouvait pas.

Citation:

---

Envoyé par gl

S'il lui est possible de passer par des vector, c'est effectivement largement préférable. Mais j'ai cru comprendre qu'il ne le pouvait pas.

---

A vrai dire, je ne vois pas en quoi il ne pourrait pas passer par un vector dans la partie de code qui l'intéresse...

La seule contrainte est de passer effectivement un tableau "C style" à la fonction unpack, et mon code montre ce qu'est bel et bien possible ;)

La gestion des données brutes au sein de sa fonction particulière en passant par un vector n'empêche strictement rien ;)

Maintenant, si les specs précisent qu'il faut éviter l'utilisation des classes de la STL, il est temps de taper du poing sur la table :D

Citation:

---

Envoyé par koala01

A vrai dire, je ne vois pas en quoi il ne pourrait pas passer par un vector dans la partie de code qui l'intéresse...

La seule contrainte est de passer effectivement un tableau "C style" à la fonction unpack, et mon code montre ce qu'est bel et bien possible ;)

---

Au temps pour moi, j'ai lu trop rapidement sa justification quant à l'utilisation d'un tableau de char. Il ne parle effectivement que de la contrainte sur la signature de la fonction unpack().

Ta méthode est donc tout à fait applicable ici.

Citation:

---

Envoyé par gl

Au temps pour moi, j'ai lu trop rapidement sa justification quant à l'utilisation d'un tableau de char. Il ne parle effectivement que de la contrainte sur la signature de la fonction unpack().

Ta méthode est donc tout à fait applicable ici.

---

Que celui qui n'a jamais lu une intervention trop rapidement te jette la première pierre...

Ce ne sera pas moi :D

Merci pour votre aide,

Je nái pas eu encore le temps d'essayer mais je suis confiant, je vous tiens au courant !

Salut à tous

Finalement j'ai eu le temps de me remettre sur le problème.

Pour une raison intrinsèque à l'environnement de test il m'est impossible d'inclure <vector>...

J'ai donc contourné/résolu le problème via un memcopy

Code:

---

1 2 3 4 5

char msg[]= {0x02,0x04,0xC0,0x00,0x45,0x85,0x60,0x3C,0x48,0x1A,0x71,0x03,0xFC,0x06,0xA0,0x8F,0x60,0xAC,0x80};   char *p=new char[]; memcpy (p,msg,sizeof(msg));

---

L'affichage du String est toujours tronqué, mais l'unpacking se réalise sur la totalité du message. En fait sur ce problème, je voulais travailler avec des donées brutes et non pas sur leur représentation ascii. D'ou ma confusion puisque je basait ma réflexion sur ce que "je voyait" en d'autres termes ce qui était affichable en Ascii donc forcément tronqué car 0x00.
:king:
Merci pour votre aide et conseils.