Discussion :

[TheCaribouX]

Bonjour tout le monde,

bon là j'ai un peu honte de le demander, mais je suis en train de perdre un temps pas possible sur un probleme bidon...si quelqu'un a la générosité de m'aider (ne serait-ce que par pitié...), c'est volontiers.

Soit un string du format "AA2F4C..." bref, qui ne contient que des charactères héxa, j'aimerais en obtenir un tableau de byte {0xAA, 0x2F, 0x4C,...}. Mon problème étant que pour l'instant je n'arrive qu'a remplir mon tableau avec la valeur hexa de chaque caractère ({0x65, 0x65, 0x50, 0x70,....}).

Je ne demande évidemment pas la solution, mais si vous avez des indices sur la direction dans laquelle je dois aller (ma direction actuelle étant droit dans le mur ), merci d'avance!

A+

[Mac LAK]

Indice : sscanf("%02x")... Faut juste découper un peu ta chaîne avant, c'est à dire faire une conversion manuelle de deux chiffres hexa consécutifs fournis via un char*.

[TheCaribouX]

Ca a l'air de pas trop mal fonctionner

Code :

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

1
2
3
4
5
6
7
8
9
10
	int i = 0;
	char ch[2];
 
	for(i=0;i<20;i++){
		ch[0] = string[(i*2)];
		ch[1] = string[(i*2)+1];
		sscanf(ch,"%02X",&res[i]);
	}
 
	return res;

Si ça te parait acceptable (qui sait...), je vais me contenter de ca, parce que le resultat a l'air d'aller!

Merci de ton aide!

[Mac LAK]

Rajoutes "char ch[3]" et un "ch[2]=0", et ça sera encore mieux (zéro terminal de la chaîne).

[TheCaribouX]

Adjugé!

Merci beaucoup et bonne journée!

[nicolas.sitbon]

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
17
18
19
20
21
22
#include <stdio.h>
#include <string.h>
#include <assert.h>
 
int main(void)
{
   char const * const hex_string = "00112233445566778899AABBCCDDEEFF";
   size_t const hex_string_length = strlen(hex_string);
   unsigned char res[hex_string_length / 2]; /* VLA */ 
 
   assert((hex_string_length % 2) == 0);   
 
   for(size_t i = 0; i < hex_string_length; i += 2)
   {
      if(sscanf(hex_string + i, "%02hhX", &res[i / 2]) == 0)
      {
         break; /* handle error */
      }
   }
 
   return 0;
}

[Mac LAK]

Ne compile pas sous VS2008...

Version corrigée :

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
17
18
19
20
21
22
23
24
25
26
27
28
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include <assert.h>
 
int main(void)
{
   char const * const hex_string = "00112233445566778899AABBCCDDEEFF";
   size_t hex_string_length = strlen(hex_string);
   unsigned char* res = malloc(hex_string_length / 2);
   size_t i ;
   unsigned short int scchar ;
 
 
   assert((hex_string_length % 2) == 0);   
 
   for(i = 0; i < hex_string_length; i += 2)
   {
      if(sscanf(hex_string + i, "%02cX", &scchar) == 0)
      {
         break; /* handle error */
      } else
          res[i / 2] = (unsigned char)scchar ;
   }
   if (res)
      free(res);
   return 0;
}

EDIT : Re-corrigé sur le sscanf, débordement de mémoire (lecture unsigned short int => boum en debug sous VS).

[Mat.M]

Soit un string du format "AA2F4C..." bref, qui ne contient que des charactères héxa,A+

une chaine de charactères ne peut pas contenir des charactères hexadécimales c'est une représentation ! censée faciliter les choses.
On utilise l'hexa afin d'effectuer une sorte d'aggrégation de la représentation binaire.
Pour moi une chaine de charactères c'est des 1 et des 0 soit du courant électrique ou non au niveau des diodes de ta Random Access Memory.

[TheCaribouX]

une chaine de charactères ne peut pas contenir des charactères hexadécimales c'est une représentation ! censée faciliter les choses.
On utilise l'hexa afin d'effectuer une sorte d'aggrégation de la représentation binaire.
Pour moi une chaine de charactères c'est des 1 et des 0 soit du courant électrique ou non au niveau des diodes de ta Random Access Memory.

Le principal étant que j'aie été compris, en fin de compte..

Quel avantage aurait la solution numéro deux par rapport à celle du début?

[nicolas.sitbon]

Ne compile pas sous VS2008...

Version corrigée :

Change de compilateur, code conforme C99, testé sur 3 archis dont Windows.
Ton code de format n'est pas bon (%cX).

[Mac LAK]

Change de compilateur, code conforme C99, testé sur 3 archis dont Windows.
Ton code de format n'est pas bon (%cX).

VS 2008 reste un des compilateurs les plus utilisés : suivre la norme, c'est bien, mais il ne faut pas non plus se mettre des œillères... Surtout quand il s'agit du C, quand on voit le nombre hallucinant de plates-formes (et de compilateurs) spécifiques.

[gl]

Change de compilateur, code conforme C99, testé sur 3 archis dont Windows.

Mes VLAs n'étant pas correctement supportés ni sous Visual ni sous gcc, ça commence à être compliqué de changer de compilateur surtout lorsque l'on n'a pas les moyens (notamment lors d'un usage personnel) d'acheter un compilateur supportant intégralement C99.

En outre, indépendamment du support de C99 par les compilateurs, j'ai des doutes sur l'intérêt du VLA (entre autre sur la gestion des erreurs mémoires).

[nicolas.sitbon]

Mes VLAs n'étant pas correctement supportés ni sous Visual ni sous gcc, ça commence à être compliqué de changer de compilateur surtout lorsque l'on n'a pas les moyens (notamment lors d'un usage personnel) d'acheter un compilateur supportant intégralement C99.

En payant, y'en a tout casser pour 250 euros le couple comeau + dinkumware, sinon, en gratuit, pour le compilo, il y a Pelles C qui offre un bon support du C99.

En outre, indépendamment du support de C99 par les compilateurs, j'ai des doutes sur l'intérêt du VLA (entre autre sur la gestion des erreurs mémoires).

Je l'ai utilisé ici pour ça simplicité, et cet argument que vous mettez tous en avant, n'est à mon sens pas recevable si l'on vérifie la taille au préalable, il n'y a pas moins de gestion d'erreur que sur un tableau normal, alors soit vous êtes cohérent avec vous même et vous n'utilisez plus les tableaux automatiques (sur la pile), soit vous admettez qu'un VLA n'est pas plus dangereux.
Cordialement.

[orfix]

Mes VLAs n'étant pas correctement supportés ni sous Visual ni sous gcc ...

Chez moi avec gcc v 4.3.2 le code de nicolas.sitbon compile parfaitement.
Concernant le support des VLA, sur la page Status of C99 features in GCC c'est marqué Done !

[gl]

Concernant le support des VLA, sur la page Status of C99 features in GCC c'est marqué Done !

Tiens, c'est passé en done dans la mainline. Ça ne l'est toutefois pas dans les versions release, y compris la 4.4

Mais c'est effectivement une bonne nouvelle pour la suite.

[gl]

En payant, y'en a tout casser pour 250 euros le couple comeau + dinkumware, sinon, en gratuit, pour le compilo, il y a Pelles C qui offre un bon support du C99.

Le souci, c'est que 250€ ce n'est pas anodin pour tout le monde. Pour un usage professionnel, ce n'est effectivement pas grand chose (et encore pour certains PME, ça peut être un frein), mais pour un usage personnel (je pense entre autre aux étudiants), ça commence à faire pas mal.

Et il n'en reste pas moins vrai que deux compilateurs énormément utilisés ne supporte pas intégralement le C99. On peut trouver cela regrettable (et je fais parti de ceux qui le pensent), mais c'est comme ça.

Après, il est effectivement possible de faire du pur C99, c'est un choix tout ce qu'il y a de plus respectable, mais on se coupe alors la portabilité sur certains compilateurs (ce qui peut être dans certains cas sans grande importance je te l'accorde).

Je l'ai utilisé ici pour ça simplicité, et cet argument que vous mettez tous en avant, n'est à mon sens pas recevable si l'on vérifie la taille au préalable, il n'y a pas moins de gestion d'erreur que sur un tableau normal, alors soit vous êtes cohérent avec vous même et vous n'utilisez plus les tableaux automatiques (sur la pile), soit vous admettez qu'un VLA n'est pas plus dangereux.

La différence, est qu'avec une variable automatique tu connais à priori la taille, pas forcément sur un VLA. Pour reprendre ton objection, lorsque les tailles en jeu commence à devenir importantes, je n'utilise effectivement plus de tableaux automatiques.

Après, il est effectivement possible de vérifier la taille avant de créer un VLA mais dans ce cas que faire ?

• Utiliser un VLA si la taille est faible et l'allocation dynamique dans les cas contraire, bref avoir deux branches de code en fonction de la taille obtenue ? Je pense que nous sommes d'accord pour dire que cela complique le code et n'apporte rien.
• Sortir en erreur si la taille nous semble trop importante ? Pourquoi pas mais dans ce cas d'une part on rejette arbitrairement un traitement qui pourrait éventuellement être faisable avec une allocation dynamique classique et d'autre part je ne vois pas, sauf pour quelque cas particuliers, le gain du VLA par rapport à l'utilisation d'un tableau automatique de taille "suffisamment grande" mis à part une légère économie de mémoire qui est bien souvent inutile.
• Il reste l'alternative d'utiliser un VLA sans se soucier de la taille et de se prendre un arrêt brutal du programme si elle était trop importante. Dans certains cas c'est une alternative envisageable, mais qu'il n'est pas possible de généraliser.

Je reconnais volontiers que la gestion mémoire en C est fastidieuse, compliquée et source d'erreur et que la mise en place des VLAs part d'une très bonne intention, mais globalement[1] je ne suis pas convaincu du résultat.


[1] Il existe certains cas où je n'ai rien contre l'utilisation de VLA bien au contraire : PoC, démonstrateur, maquette, etc.
Mais les utiliser dans des contextes où la gestion des erreurs et des cas limites est secondaire par rapport à la durée de développement est une choses, les généraliser à tous les contextes en est une autre.

[nicolas.sitbon]

Pour moi l'utilisation d'un VLA intervient dans les mêmes conditions qu'un tableau automatique classique, on a besoin d'un tableau de taille raisonnable, c'est effectivement souvent le cas comme tu le dis dans les Poc ou les maquettes. Je ne suis pas en train de dire que les VLAs vont remplacer les tableaux dynamiques, simplement, la où peut être utiliser un tableau automatique, un VLA peut faire l'affaire et ajouter une touche de dynamisme. Dans un cas comme dans le code que j'ai donné, l'utilisation du VLA est pour moi correct, mis à part que je ne vérifie pas la taille.
Cordialement.

[Mac LAK]

Le souci, c'est que 250€ ce n'est pas anodin pour tout le monde. Pour un usage professionnel, ce n'est effectivement pas grand chose (et encore pour certains PME, ça peut être un frein), mais pour un usage personnel (je pense entre autre aux étudiants), ça commence à faire pas mal.

Quitte à dépenser autant, pour ma part, ce sera plutôt une licence C++ Builder plutôt qu'un "simple" compilateur C... Ce ne sera sûrement pas une norme qui me fera changer mes outils, surtout si c'est pour devoir jeter les IDE que j'apprécie.

Et il n'en reste pas moins vrai que deux compilateurs énormément utilisés ne supporte pas intégralement le C99. On peut trouver cela regrettable (et je fais parti de ceux qui le pensent), mais c'est comme ça.

Pour moi, mais je n'oblige personne à me suivre aveuglément là-dessus, c'est rédhibitoire. Dans mon domaine, beaucoup d'outils ne sont utilisés que s'ils ont une certaines pérennité et/ou "vécu". On est donc obligés de se fader des compilateurs exotiques "100% normeless", des versions datant de la genèse (GCC 2.x ou VC++ 6, par exemple), et au final la portabilité impose souvent de faire du C dans le sous-ensemble commun C/C++ exclusivement.

Effectivement, c'est sûrement très dommage, mais c'est ainsi : le C est un langage "de base", et parfois le seul et unique (hors ASM) sur certains systèmes, et ces systèmes ne sont parfois même plus maintenus. Il faut alors impérativement "faire avec", et savoir utiliser du code adéquat.

C'est un avis personnel, mais mettre la norme en avant de façon inconditionnelle, sans penser au parc installé de compilateurs, c'est un peu comme dire à quelqu'un qui a des soucis avec les chaînes en C d'utiliser std::string : oui, c'est peut-être plus pratique, "plus mieux" et tout et tout, mais ce n'est pas la bonne réponse pour autant.

C'est un problème d'approche plus ou moins pragmatique du langage : certains voient le langage (et donc sa norme) comme une fin en soi qui nécessite les outils adéquats, d'autres comme un outil (se basant sur un langage plus ou moins bien supporté) devant répondre au mieux des besoins.

[gl]

Pour moi l'utilisation d'un VLA intervient dans les mêmes conditions qu'un tableau automatique classique, on a besoin d'un tableau de taille raisonnable, c'est effectivement souvent le cas comme tu le dis dans les Poc ou les maquettes. Je ne suis pas en train de dire que les VLAs vont remplacer les tableaux dynamiques, simplement, la où peut être utiliser un tableau automatique, un VLA peut faire l'affaire et ajouter une touche de dynamisme.

Dans un tel cas, oui je suis d'accord qu'un VLA peut être adapté. Même si le gain par rapport à un tableau classique de taille "suffisante" est somme toute assez faible dans de nombreux cas.