Discussion :

[Herode]

Bonjour à tous,

j'ai un petit souci, dû au fait que le compilateur refuse de transtyper du const char* (qui m'arrive en entrée) vers du const unsigned char*, ce dernier type étant requis par une librairie que je dois utiliser.

Remarquez que je ne lui en veux pas, sur le fond, et je conçois sa réticence. Cependant, avant de forcer le transtypage à coups de reinterpret_cast< >, j'aimerais comprendre de quoi il retourne. Aussi me suis-je penché sur le Livre Sacré, qui dit à propos de ces types :

Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation.
For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible
bit patterns of the value representation represent numbers.

Je ne comprends pas cette dernière phrase. Quelqu'un pourrait-il m'expliquer ça, histoire que je devine comment traiter le problème ????????

[loufoque]

Tu t'en fous, caste.

[Jean-Marc.Bourguet]

j'ai un petit souci, dû au fait que le compilateur refuse de transtyper du const char* (qui m'arrive en entrée) vers du const unsigned char*, ce dernier type étant requis par une librairie que je dois utiliser.

Normal, ce sont des pointeurs vers des types différents. Il n'y a pas de raisons pour laquelle ce devrait être permis.

Remarquez que je ne lui en veux pas, sur le fond, et je conçois sa réticence. Cependant, avant de forcer le transtypage à coups de reinterpret_cast< >, j'aimerais comprendre de quoi il retourne. Aussi me suis-je penché sur le Livre Sacré, qui dit à propos de ces types :

Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation.
For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible
bit patterns of the value representation represent numbers.

Je ne comprends pas cette dernière phrase.

Pour comprendre, il faut savoir que si un type T occupe sizeof(T) bytes, la norme permet que d'une part certains bits ne participent pas à la valeur et d'autre part que certaines combinaisons des bits participants à la valeur soient interdites. Ce paragraphe dit que d'une part pour les 3 types caractères (char, unsigned char et signed char), tous les bits participent à la valeur et d'autre part que pour unsigned char il n'y a pas de combinaisons interdites. Ce qu'on savait aussi par 3.9.1/4 qui impose pour les types non signés d'avoir 2^N valeurs où N est le nombre de bits participant à la valeur (donc on sait aussi que pour unsigned char, il n'y a pas de combinaisons représentant la même valeur). On n'a pas ces deux contraintes pour signed char qui donc peut avoir des valeurs interdites et des combinaisons synonymes.

Comme plus haut il est écrit que les 3 types ont la même taille et la contrainte d'alignment (en fait il ne peut pas y en avoir car size(char) == 1) tu peux faire un cast de char const* en unsigned char const* l'âme en paix. L'inverse est moins sûr s'il y a des valeurs interdites ou synonymes pour char. Les valeurs synonymes dans char, je ne vois pas d'architecture où ce soit possible. Les valeurs interdites, en complément à 1 ou en grandeur et signe, il peut être sensé d'interdire le -0.

[Herode]

Voilà qui est limpide. Merci pour ce petit cours 8)