alors que je m'attendrais (et que je voudrais) quelque chose du genre:
0x00aa=0x00
Vous avez des idées?
Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un typedef sur unsigned char et donc data1 et data2 devraient etre affiche comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir vers un fichier et regarder avec un editeur hexa,...)
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
alors que je m'attendrais (et que je voudrais) quelque chose du genre:
0x00aa=0x00
Vous avez des idées?
Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un
typedef sur unsigned char et donc data1 et data2 devraient etre affiche
comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le
voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir
vers un fichier et regarder avec un editeur hexa,...)
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
alors que je m'attendrais (et que je voudrais) quelque chose du genre:
0x00aa=0x00
Vous avez des idées?
Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un typedef sur unsigned char et donc data1 et data2 devraient etre affiche comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir vers un fichier et regarder avec un editeur hexa,...)
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
alors que je m'attendrais (et que je voudrais) quelque chose du genre:
0x00aa=0x00
Vous avez des idées?
Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un typedef sur unsigned char et donc data1 et data2 devraient etre affiche comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir vers un fichier et regarder avec un editeur hexa,...)
Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont utilisés avant leur initialisation. On en a parlé ici il n'y a pas si longtemps ;)
Ca donne bien le resultat attendu (avec des variables correctement initialisees). A la premiere lecture, j'ai trouve etrange l'usage explicite du prefixe "0x", parce qu'on peut l'obtenir avec le manipulateur showbase (il faut aussi internal pour le remplissage). On devrait donc obtenir le resultat comme ceci :
A ma grande surprise, showbase n'ajoute pas le prefixe de base pour a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun a toutes les bases ). Jusqu'a present je pensais que le prefixe etait ajouté systematiquement, parce que je n'etait jamais tombé sur le cas particulier de 0, ni vu dans aucune doc qu'il y avait un comportement special.
alors que je m'attendrais (et que je voudrais) quelque chose du genre:
0x00aa=0x00
Vous avez des idées?
Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un
typedef sur unsigned char et donc data1 et data2 devraient etre affiche
comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le
voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir
vers un fichier et regarder avec un editeur hexa,...)
Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont
utilisés avant leur initialisation. On en a parlé ici il n'y a pas si
longtemps ;)
Ca donne bien le resultat attendu (avec des variables correctement
initialisees). A la premiere lecture, j'ai trouve etrange l'usage
explicite du prefixe "0x", parce qu'on peut l'obtenir avec le
manipulateur showbase (il faut aussi internal pour le remplissage).
On devrait donc obtenir le resultat comme ceci :
A ma grande surprise, showbase n'ajoute pas le prefixe de base pour
a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun
a toutes les bases ). Jusqu'a present je pensais que le prefixe etait
ajouté systematiquement, parce que je n'etait jamais tombé sur le
cas particulier de 0, ni vu dans aucune doc qu'il y avait un
comportement special.
alors que je m'attendrais (et que je voudrais) quelque chose du genre:
0x00aa=0x00
Vous avez des idées?
Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un typedef sur unsigned char et donc data1 et data2 devraient etre affiche comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir vers un fichier et regarder avec un editeur hexa,...)
Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont utilisés avant leur initialisation. On en a parlé ici il n'y a pas si longtemps ;)
Ca donne bien le resultat attendu (avec des variables correctement initialisees). A la premiere lecture, j'ai trouve etrange l'usage explicite du prefixe "0x", parce qu'on peut l'obtenir avec le manipulateur showbase (il faut aussi internal pour le remplissage). On devrait donc obtenir le resultat comme ceci :
A ma grande surprise, showbase n'ajoute pas le prefixe de base pour a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun a toutes les bases ). Jusqu'a present je pensais que le prefixe etait ajouté systematiquement, parce que je n'etait jamais tombé sur le cas particulier de 0, ni vu dans aucune doc qu'il y avait un comportement special.
| Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont | utilisés avant leur initialisation. On en a parlé ici il n'y a pas si | longtemps ;)
sauf si uint8_t est un unsigned char :-)
Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?
Michel Decima <michel.decima@orange-ft.com> writes:
| Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont
| utilisés avant leur initialisation. On en a parlé ici il n'y a pas si
| longtemps ;)
sauf si uint8_t est un unsigned char :-)
Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?
| Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont | utilisés avant leur initialisation. On en a parlé ici il n'y a pas si | longtemps ;)
sauf si uint8_t est un unsigned char :-)
Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?
Sylvain
Michel Decima wrote on 07/03/2008 21:21:
sauf si uint8_t est un unsigned char :-)
Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?
voire parce qu'un type utilisateur influencerait le contenu mémoire ?
Sylvain.
Michel Decima wrote on 07/03/2008 21:21:
sauf si uint8_t est un unsigned char :-)
Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?
voire parce qu'un type utilisateur influencerait le contenu mémoire ?
Ca donne bien le resultat attendu (avec des variables correctement initialisees). A la premiere lecture, j'ai trouve etrange l'usage explicite du prefixe "0x", parce qu'on peut l'obtenir avec le manipulateur showbase (il faut aussi internal pour le remplissage). On devrait donc obtenir le resultat comme ceci :
A ma grande surprise, showbase n'ajoute pas le prefixe de base pour a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun a toutes les bases ). Jusqu'a present je pensais que le prefixe etait ajouté systematiquement, parce que je n'etait jamais tombé sur le cas particulier de 0, ni vu dans aucune doc qu'il y avait un comportement special.
La, c'est quand meme plus clair, parce que le man printf(3) me dit que pour le caractere #, on a
"For x and X conversions, a non-zero result has the string 0x (or 0X for X conversions) prepended to it."
Les deux langages on le meme comportement, au fond, c'est pratique, mais est-ce que c'est standard ?
Oui:-(. J'ai rencontré le même problème, il y a peu. Je l'ai résolu en sortant le "0x" explicitement. (À vrai dire, ça m'arrangeait, parce que je voulais l'x dans "0x" minuscule, mais les chiffres hex majuscule.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 7 mar, 14:47, Michel Decima <michel.dec...@orange-ft.com> wrote:
Ca donne bien le resultat attendu (avec des variables
correctement initialisees). A la premiere lecture, j'ai trouve
etrange l'usage explicite du prefixe "0x", parce qu'on peut
l'obtenir avec le manipulateur showbase (il faut aussi
internal pour le remplissage). On devrait donc obtenir le
resultat comme ceci :
A ma grande surprise, showbase n'ajoute pas le prefixe de base pour
a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun
a toutes les bases ). Jusqu'a present je pensais que le prefixe etait
ajouté systematiquement, parce que je n'etait jamais tombé sur le
cas particulier de 0, ni vu dans aucune doc qu'il y avait un
comportement special.
La, c'est quand meme plus clair, parce que le man printf(3) me
dit que pour le caractere #, on a
"For x and X conversions, a non-zero result has the string
0x (or 0X for X conversions) prepended to it."
Les deux langages on le meme comportement, au fond, c'est pratique,
mais est-ce que c'est standard ?
Oui:-(. J'ai rencontré le même problème, il y a peu. Je l'ai
résolu en sortant le "0x" explicitement. (À vrai dire, ça
m'arrangeait, parce que je voulais l'x dans "0x" minuscule, mais
les chiffres hex majuscule.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ca donne bien le resultat attendu (avec des variables correctement initialisees). A la premiere lecture, j'ai trouve etrange l'usage explicite du prefixe "0x", parce qu'on peut l'obtenir avec le manipulateur showbase (il faut aussi internal pour le remplissage). On devrait donc obtenir le resultat comme ceci :
A ma grande surprise, showbase n'ajoute pas le prefixe de base pour a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun a toutes les bases ). Jusqu'a present je pensais que le prefixe etait ajouté systematiquement, parce que je n'etait jamais tombé sur le cas particulier de 0, ni vu dans aucune doc qu'il y avait un comportement special.
La, c'est quand meme plus clair, parce que le man printf(3) me dit que pour le caractere #, on a
"For x and X conversions, a non-zero result has the string 0x (or 0X for X conversions) prepended to it."
Les deux langages on le meme comportement, au fond, c'est pratique, mais est-ce que c'est standard ?
Oui:-(. J'ai rencontré le même problème, il y a peu. Je l'ai résolu en sortant le "0x" explicitement. (À vrai dire, ça m'arrangeait, parce que je voulais l'x dans "0x" minuscule, mais les chiffres hex majuscule.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
c'est en substance tout à fait contradictoire avec tes positions du fil précédent.
Sylvain.
James Kanze
On 8 mar, 23:40, Sylvain wrote:
James Kanze wrote on 07/03/2008 22:01:
Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne pourrait pas influencer comment on accède aux objets---quand j'accède à travers un lvalue de type char, par exemple, je n'accède qu'aux huit bits, tandis qu'avec int... Et je suis certain de ne jamais avoir dit le contraire.
La norme guarantee qu'un accès à un unsigned char fonctionne. Même si l'unsigned char n'a jamais été initialisé (mais évidemment, la valeur que tu vois n'est pas déterminé dans ce cas-là). La norme ne fait cette garantie pour aucune autre type. Et il existe bien des architectures, même aujourd'hui, où l'int contient un bit de tag, positionné implicitement je ne sais pas trop comment, et où l'accès à un int non initialisé risque de provoquer un trap hardware (ce qui résumerait en un core dump sur les systèmes dont je me sers).
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 8 mar, 23:40, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 07/03/2008 22:01:
Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
La norme guarantee qu'un accès à un unsigned char fonctionne.
Même si l'unsigned char n'a jamais été initialisé (mais
évidemment, la valeur que tu vois n'est pas déterminé dans ce
cas-là). La norme ne fait cette garantie pour aucune autre type.
Et il existe bien des architectures, même aujourd'hui, où l'int
contient un bit de tag, positionné implicitement je ne sais pas
trop comment, et où l'accès à un int non initialisé risque de
provoquer un trap hardware (ce qui résumerait en un core dump
sur les systèmes dont je me sers).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
c'est en substance tout à fait contradictoire avec tes positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne pourrait pas influencer comment on accède aux objets---quand j'accède à travers un lvalue de type char, par exemple, je n'accède qu'aux huit bits, tandis qu'avec int... Et je suis certain de ne jamais avoir dit le contraire.
La norme guarantee qu'un accès à un unsigned char fonctionne. Même si l'unsigned char n'a jamais été initialisé (mais évidemment, la valeur que tu vois n'est pas déterminé dans ce cas-là). La norme ne fait cette garantie pour aucune autre type. Et il existe bien des architectures, même aujourd'hui, où l'int contient un bit de tag, positionné implicitement je ne sais pas trop comment, et où l'accès à un int non initialisé risque de provoquer un trap hardware (ce qui résumerait en un core dump sur les systèmes dont je me sers).
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
