Bonjour,
je me pose une question concernant la lecture d'une chaîne avec
sscanf(buffer,"%02X",&byte);
je récupère donc un octet, que je veux mettre dans un unsigned char.
Mais gcc m'engueule en me disant : "format unsigned int, arg type
différent (arg 3)".
Seulement, récupérer, comme gcc préfère, dans un unsigned int (donc 4
octets) est plus emmerdant après, car on ne sait pas dans quel octet
c'est lu selon le little/big endian et ça peut faire n'importe quoi lors
du memcopy qui suit...
|> unsigned int val; |> unsigned char uc; |> sscanf(buffer, "%02X", &val); |> // les trois lignes suivantes sont équivalentes
Je mettrais bien un « assert( val ) <= UCHAR_MAX ) » ici.
Avec la chaîne de format employée, n'est-on pas certain de la véracité de cette assertion ?
--drkm
Charlie Gordon
"James Kanze" wrote in message news:
"Charlie Gordon" writes:
|> "Emmanuel Delahaye" wrote in message |> news: |> > Charlie Gordon wrote on 23/11/04 :
|> > >> je récupère donc un octet, que je veux mettre dans un unsigned |> > >> char.
|> > > uc = val & ((1 << CHAR_BIT) - 1); vs: uc = val & 0xFF;
...
|> De toute facon CHAR_BIT >= 8, sscanf() n'a lu que 2 chiffres |> hexadécimaux, et cette discussion est largement au delà des |> compétences de l'OP, sans compter que je n'ai même pas testé le |> résultat de sscanf(), ni même la pertinence du format %02X...
P't-êt' ben. Mais alors, si %02X signifie qu'on veut 8 bits, pourquoi utiliser une expression complexe qui pourraient, sur certaines machines, donner un résultat autre, plutôt qu'une expression simple et parlante qui marche partout ?
Tout à fait d'accord... ma proposition était plutôt de l'ordre de l'ironie.
-- Chqrlie.
"James Kanze" <james.kanze@free.fr> wrote in message
news:m2mzx2go1d.fsf@lns-p19-19-82-65-138-108.adsl.proxad.net...
"Charlie Gordon" <news@chqrlie.org> writes:
|> "Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> wrote in message
|> news:mn.bc977d4b1ee5d688.15512@YOURBRAnoos.fr...
|> > Charlie Gordon wrote on 23/11/04 :
|> > >> je récupère donc un octet, que je veux mettre dans un unsigned
|> > >> char.
|> > > uc = val & ((1 << CHAR_BIT) - 1);
vs: uc = val & 0xFF;
...
|> De toute facon CHAR_BIT >= 8, sscanf() n'a lu que 2 chiffres
|> hexadécimaux, et cette discussion est largement au delà des
|> compétences de l'OP, sans compter que je n'ai même pas testé le
|> résultat de sscanf(), ni même la pertinence du format %02X...
P't-êt' ben. Mais alors, si %02X signifie qu'on veut 8 bits, pourquoi
utiliser une expression complexe qui pourraient, sur certaines machines,
donner un résultat autre, plutôt qu'une expression simple et parlante
qui marche partout ?
Tout à fait d'accord... ma proposition était plutôt de l'ordre de l'ironie.
|> "Emmanuel Delahaye" wrote in message |> news: |> > Charlie Gordon wrote on 23/11/04 :
|> > >> je récupère donc un octet, que je veux mettre dans un unsigned |> > >> char.
|> > > uc = val & ((1 << CHAR_BIT) - 1); vs: uc = val & 0xFF;
...
|> De toute facon CHAR_BIT >= 8, sscanf() n'a lu que 2 chiffres |> hexadécimaux, et cette discussion est largement au delà des |> compétences de l'OP, sans compter que je n'ai même pas testé le |> résultat de sscanf(), ni même la pertinence du format %02X...
P't-êt' ben. Mais alors, si %02X signifie qu'on veut 8 bits, pourquoi utiliser une expression complexe qui pourraient, sur certaines machines, donner un résultat autre, plutôt qu'une expression simple et parlante qui marche partout ?
Tout à fait d'accord... ma proposition était plutôt de l'ordre de l'ironie.
-- Chqrlie.
James Kanze
drkm writes:
|> James Kanze writes:
|> > "Charlie Gordon" writes:
|> > |> unsigned int val; |> > |> unsigned char uc; |> > |> sscanf(buffer, "%02X", &val); |> > |> // les trois lignes suivantes sont équivalentes
|> > Je mettrais bien un « assert( val ) <= UCHAR_MAX ) » ici.
|> Avec la chaîne de format employée, n'est-on pas certain de la |> véracité de cette assertion ?
En effet. En supposant une implémentation conforme de la bibliothèque, mais je ne crois pas que ce soit souvent un problème en C. J'avoue que je ne avais pas régardé en détail le format utilisé.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
|> James Kanze <james.kanze@free.fr> writes:
|> > "Charlie Gordon" <news@chqrlie.org> writes:
|> > |> unsigned int val;
|> > |> unsigned char uc;
|> > |> sscanf(buffer, "%02X", &val);
|> > |> // les trois lignes suivantes sont équivalentes
|> > Je mettrais bien un « assert( val ) <= UCHAR_MAX ) » ici.
|> Avec la chaîne de format employée, n'est-on pas certain de la
|> véracité de cette assertion ?
En effet. En supposant une implémentation conforme de la bibliothèque,
mais je ne crois pas que ce soit souvent un problème en C. J'avoue que
je ne avais pas régardé en détail le format utilisé.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > |> unsigned int val; |> > |> unsigned char uc; |> > |> sscanf(buffer, "%02X", &val); |> > |> // les trois lignes suivantes sont équivalentes
|> > Je mettrais bien un « assert( val ) <= UCHAR_MAX ) » ici.
|> Avec la chaîne de format employée, n'est-on pas certain de la |> véracité de cette assertion ?
En effet. En supposant une implémentation conforme de la bibliothèque, mais je ne crois pas que ce soit souvent un problème en C. J'avoue que je ne avais pas régardé en détail le format utilisé.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
