Discussion :

[phoenixgreg]

Bonjour tout le monde,

Comment faire pour passer les valeurs d'un unsigned char* en hexadécimal ?

Code :

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

1
2
3
4
 
unsigned char* test = '6192';
// le passer
unsigned char* test = '1830';

Je sèche sur ce coup là ! Merci pour votre aide!

[fearyourself]

En principe, l'algorithme de base si on ignore le problème des nombres trop grands serait:

- "6192" -> 6192 (donc dans un entier)
- 6192 -> "1830"

Si on ne veut pas faire cela et qu'on veut être un peu flemmard:

Je n'ai pas de compilateur C sous la main, mais cela devrait être proche.

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
 
char* convert(const char *str) {
    // Decimal vers hexa sera au max de même taille.
    // +1 pour le ''\0'
    int n = strlen(str) + 1;
    char *res = malloc(n);
    if (!res) {
        return res;
    }
 
    int number = strtol(str, NULL, 0);
    snprintf(res, n, "%x", number);
    return res;
}
 
int main() {
    char *res = convert("6192");
    printf("%s\n", res);
    free(res), res = NULL;
	return 0;
}

[phoenixgreg]

Merci pour votre réponse seulement le type n'est pas

Code :

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

1
2
 
char* convert(const char *str) {

mais

Code :

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

1
2
 
unsigned char* convert(const unsigned char *str) {

du coup ce n'est plus compatible :s

[foetus]

Que ce soit en ANSI ou en UTF-8, les chiffres tiennent dans 7 bits donc tu peux caster joyeusement en (unsigned char*) ou (char*)

[phoenixgreg]

ça coince à cette ligne:

[fearyourself]

C'est parce que tu utilises un compilateur C++ à la place d'un compilateur C ;-)

[jcb44]

il te faut faire un cast de malloc avec (char *)

Code C :

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

 char *res =(char*)malloc(n);

[fearyourself]

il te faut faire un cast de malloc avec (char *)

Code C :

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

 char *res =(char*)malloc(n);

Pas en C... Si on DOIT faire cela, on est en train d'utiliser le mauvais compilateur.

Si on DOIT faire un cast sur un malloc, cela veut dire qu'on utilise un compilateur C++. Si on utilise un compilateur C++, alors on devrait faire du C++. Si on fait du C++, on utilise new/delete ;-)

[phoenixgreg]

Oui, donc résultat j'ai bien l'impression de m'être trompé de forum ..... désolé de vous être investi pour rien :s

[Obsidian]

Bonjour,

Oui, donc résultat j'ai bien l'impression de m'être trompé de forum ..... désolé de vous être investi pour rien :s

Non, non, c'est bien le bon forum si tu es en train de faire du C.

Le C et le C++ ont beaucoup de choses en commun, si bien qu'un compilateur C++ parviendra la plupart du temps à compiler directement un programme C, donnant l'illusion au programmeur que le C est un « sous-ensemble » du C++ et que celui-ci est implicitement compatible. En réalité, il s'agit bien d'un langage distinct qui s'est appuyé dessus et qui a laissé tel quel tout ce qui n'avait pas besoin d'être changé (ce qui, en ce sens, est une bonne idée).

La norme spécifie en revanche un certain nombre de petites différences, notamment au niveau des transtypages void (qui t'intéressent dans le cas présent). Ce que fearyourself essaie de t'expliquer, en revanche, c'est que cette erreur apparemment anodine (et assez courante) traduit en fait que ton compilateur pense que ton programme est écrit en C++ et va orienter toute sa compilation en ce sens, ce qui risque de provoquer plus tard des erreurs plus importantes et beaucoup plus difficilement décelables.

Moralité, soit tu utilises un compilateur C, soit tu paramètres explicitement le compilateur actuel pour lui préciser que le programme en question est du C. Généralement, l'extension du nom de fichier est un indice suffisant pour lui. Mais cela reste à vérifier. Peut-être faudra-t-il modifier certaines options dans l'IDE que tu utilises.

[Bktero]

Si on utilise un compilateur C++, alors on devrait faire du C++. Si on fait du C++, on utilise new/delete ;-)

J'aurais plutôt dit "en C++, tu ne fais ni malloc ni free, ni new ni delete, tu fais des pointeurs intelligents" mais on diverge un peu

Merci pour votre réponse seulement le type n'est pas

Code :

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

1
2
 
char* convert(const char *str) {

mais

Code :

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

1
2
 
unsigned char* convert(const unsigned char *str) {

du coup ce n'est plus compatible :s

Je me suis posé la question dés ton premier message : pourquoi utiliser des unsigned char* pour stocker des chaines de caractères ?

[phoenixgreg]

Alors oui en effet, j'aurai du beaucoup mieux préciser la chose, j'ai un compilateur C++ sauf que le code que je dois faire se trouve dans un

Code :

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

1
2
3
4
 
extern "C"{	
...
}

voilà voilà ...
Ensuite la fonction par laquelle je passe demande un Unsigned char * pour passer mes données.

[fearyourself]

Alors si tu es obligé de faire cela, oui il te faudra un cast tristement

Et ta question est une question C, donc c'était le bon endroit.

[Bktero]

Je m'attendais à cette réponse. C'est un peu dommage / bizarre mais si cela fonctionne c'est ce qui compte.

Si tu es en C++, pense à faire tes cast avec les opérateurs dédiés, dans cas sans doute static_cast. Extern C n'est qu'une indication pour le linker, donc tu dois pouvoir compiler tout ce qui pur C++ dedans.

[fearyourself]

Enfin, l'autre question serait plutôt de voir pourquoi tu appelles ce genre de code depuis le C++ vers du C?

En principe, on utilise le extern "C" pour préserver les noms des fonctions pour un futur dlsym. Ici, ce n'est pas la peine. Aussi, ma solution était une solution de flemmard avec une allocation dynamique. Dois-tu garder ta signature de ta méthode convert?

[phoenixgreg]

Je suis en train d'implémenter une librairie en C++ dans un environnement Delphi, voilà le problème