J'ai un probleme avec cet algo de calcul de crc32 sur ia64:
long crc = 0xFFFFFFFF;
if (buf != NULL) {
while (len > 0) {
crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) &
0xff]);
buf++;
len--;
}
}
Le (long) vient me mettre la grouille et j'ai aucune idee comment
corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse,
si je pouvais avoir l'explication theorique avec ... Parce que que je
me dise que le long fait 8 bits, ben ca me change pas grand chose ...
sur ia64:
./a.out TEST
O=EEEA93B8
sur i386:
./a.out TEST
O=11156C47
Voici le programme de test complet, a compiler avec juste g++
monfichier.c, a tester avec ./a.out monmot :
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
Le (long) vient me mettre la grouille et j'ai aucune idee comment corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse, si je pouvais avoir l'explication theorique avec ... Parce que que je me dise que le long fait 8 bits, ben ca me change pas grand chose ... A première vue, votre code n'est pas portable, en ce sens qu'il suppose
un long de 32 bits, sizeof(long)==4. Remplacez long par un type à taille fixe de 32 bits. A mon avis en unsigned. S'il n'existe pas, vous le fabriquez, avec des #if, les constantes de limits.h, et des typedef.
sur ia64: ./a.out TEST OîEA93B8
sur i386: ./a.out TEST O156C47
Voici le programme de test complet, a compiler avec juste g++ monfichier.c, a tester avec ./a.out monmot : Bien de poster un code compilable. Même si c'est du C++ ;-) Notez que
ce n'est pas grave, la question telle qu'elle est posée au dessus est en charte. En fait, c'est une gfonction C que vous utilisez en C++, je suppose.
-- Pierre Maurette
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64:
long crc = 0xFFFFFFFF;
if (buf != NULL) {
while (len > 0) {
crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) &
0xff]);
buf++;
len--;
}
}
Le (long) vient me mettre la grouille et j'ai aucune idee comment
corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse,
si je pouvais avoir l'explication theorique avec ... Parce que que je
me dise que le long fait 8 bits, ben ca me change pas grand chose ...
A première vue, votre code n'est pas portable, en ce sens qu'il suppose
un long de 32 bits, sizeof(long)==4.
Remplacez long par un type à taille fixe de 32 bits. A mon avis en
unsigned. S'il n'existe pas, vous le fabriquez, avec des #if, les
constantes de limits.h, et des typedef.
sur ia64:
./a.out TEST
OîEA93B8
sur i386:
./a.out TEST
O156C47
Voici le programme de test complet, a compiler avec juste g++
monfichier.c, a tester avec ./a.out monmot :
Bien de poster un code compilable. Même si c'est du C++ ;-) Notez que
ce n'est pas grave, la question telle qu'elle est posée au dessus est
en charte. En fait, c'est une gfonction C que vous utilisez en C++, je
suppose.
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
Le (long) vient me mettre la grouille et j'ai aucune idee comment corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse, si je pouvais avoir l'explication theorique avec ... Parce que que je me dise que le long fait 8 bits, ben ca me change pas grand chose ... A première vue, votre code n'est pas portable, en ce sens qu'il suppose
un long de 32 bits, sizeof(long)==4. Remplacez long par un type à taille fixe de 32 bits. A mon avis en unsigned. S'il n'existe pas, vous le fabriquez, avec des #if, les constantes de limits.h, et des typedef.
sur ia64: ./a.out TEST OîEA93B8
sur i386: ./a.out TEST O156C47
Voici le programme de test complet, a compiler avec juste g++ monfichier.c, a tester avec ./a.out monmot : Bien de poster un code compilable. Même si c'est du C++ ;-) Notez que
ce n'est pas grave, la question telle qu'elle est posée au dessus est en charte. En fait, c'est une gfonction C que vous utilisez en C++, je suppose.
-- Pierre Maurette
alian
Ca marche avec -1 en effet, un cast avec (int) au lieu de (long), et l'utilisation de LIMITED_32 ... Et ia64, oui c'est de l'itanium (4 proc a 2400 et 8Go de Ram, oui ca compile bien :-)
Ca marche avec -1 en effet, un cast avec (int) au lieu de (long), et
l'utilisation de LIMITED_32 ...
Et ia64, oui c'est de l'itanium (4 proc a 2400 et 8Go de Ram, oui ca
compile bien :-)
Ca marche avec -1 en effet, un cast avec (int) au lieu de (long), et l'utilisation de LIMITED_32 ... Et ia64, oui c'est de l'itanium (4 proc a 2400 et 8Go de Ram, oui ca compile bien :-)
Blaise Potard
wrote:
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
Le (long) vient me mettre la grouille et j'ai aucune idee comment corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse, si je pouvais avoir l'explication theorique avec ... Parce que que je me dise que le long fait 8 bits, ben ca me change pas grand chose ...
Il faut dire que ton code est un peu osé, il suppose implicitement qu'un long est codé sur 32 bits. Bon, en remplaçant ta première ligne par 'long crc = -1' ça devrait tomber en marche.
L'explication est relativement simple, quand on y pense : ton algo de calcul du crc suppose que ta variable crc est initialisée avec un nombre ne contenant que des 1 en binaire, et en l'initialisant à 0xFFFFFFFF ça marche avec des long sur 32 bits, mais pas avec des long plus grands, tout simplement, donc pas sur une archi qui a des long sur 64 bits. Bon, maintenant que j'y pense, il n'est pas impossible que mon hack ne marche pas sur des architecture ou le -1 n'est pas codé par '0b11...11', mais :
1) je pense que de toute manière l'algo ne fonctionerait plus du tout 2) est-ce que ça existe vraiment (encore) ce genre d'archi ?
P.S.: Quand tu parles d'ia64, tu parles de x86-64, ou de l'Itanium ? Simple curiosité.
alian@cpan.org wrote:
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64:
long crc = 0xFFFFFFFF;
if (buf != NULL) {
while (len > 0) {
crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) &
0xff]);
buf++;
len--;
}
}
Le (long) vient me mettre la grouille et j'ai aucune idee comment
corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse,
si je pouvais avoir l'explication theorique avec ... Parce que que je
me dise que le long fait 8 bits, ben ca me change pas grand chose ...
Il faut dire que ton code est un peu osé, il suppose implicitement qu'un
long est codé sur 32 bits. Bon, en remplaçant ta première ligne par
'long crc = -1' ça devrait tomber en marche.
L'explication est relativement simple, quand on y pense : ton algo de
calcul du crc suppose que ta variable crc est initialisée avec un nombre
ne contenant que des 1 en binaire, et en l'initialisant à 0xFFFFFFFF ça
marche avec des long sur 32 bits, mais pas avec des long plus grands,
tout simplement, donc pas sur une archi qui a des long sur 64 bits. Bon,
maintenant que j'y pense, il n'est pas impossible que mon hack ne marche
pas sur des architecture ou le -1 n'est pas codé par '0b11...11', mais :
1) je pense que de toute manière l'algo ne fonctionerait plus du tout
2) est-ce que ça existe vraiment (encore) ce genre d'archi ?
P.S.: Quand tu parles d'ia64, tu parles de x86-64, ou de l'Itanium ?
Simple curiosité.
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
Le (long) vient me mettre la grouille et j'ai aucune idee comment corriger ca. Est ce que qqn a une idee ? Pis comme je suis une chiasse, si je pouvais avoir l'explication theorique avec ... Parce que que je me dise que le long fait 8 bits, ben ca me change pas grand chose ...
Il faut dire que ton code est un peu osé, il suppose implicitement qu'un long est codé sur 32 bits. Bon, en remplaçant ta première ligne par 'long crc = -1' ça devrait tomber en marche.
L'explication est relativement simple, quand on y pense : ton algo de calcul du crc suppose que ta variable crc est initialisée avec un nombre ne contenant que des 1 en binaire, et en l'initialisant à 0xFFFFFFFF ça marche avec des long sur 32 bits, mais pas avec des long plus grands, tout simplement, donc pas sur une archi qui a des long sur 64 bits. Bon, maintenant que j'y pense, il n'est pas impossible que mon hack ne marche pas sur des architecture ou le -1 n'est pas codé par '0b11...11', mais :
1) je pense que de toute manière l'algo ne fonctionerait plus du tout 2) est-ce que ça existe vraiment (encore) ce genre d'archi ?
P.S.: Quand tu parles d'ia64, tu parles de x86-64, ou de l'Itanium ? Simple curiosité.
Pierre Maurette
[...]
tu peux corriger un peu plus proprement en utilisant un cast vers int32_t, ou alors tu peux déclarer ton tableau en int32_t (ce qui te permet d'économiser un peu de place en mémoire, de te débarasser du cast, et en plus c'est un peu plus logique). Il faut probablement ajouter un #include <inttypes.h> inttypes.h, et plus précisément stdint.h, est C99. Donc, pas C++, sauf
à utiliser la bibliothèque Boost (cstdint.hpp). Sinon, il faut donc soit utiliser des entiers à taille fixe propres à l'implémentation, soit les fabriquer.
-- Pierre Maurette
[...]
tu peux corriger un peu plus proprement en utilisant un cast vers
int32_t, ou alors tu peux déclarer ton tableau en int32_t (ce qui te
permet d'économiser un peu de place en mémoire, de te débarasser du
cast, et en plus c'est un peu plus logique). Il faut probablement
ajouter un #include <inttypes.h>
inttypes.h, et plus précisément stdint.h, est C99. Donc, pas C++, sauf
à utiliser la bibliothèque Boost (cstdint.hpp). Sinon, il faut donc
soit utiliser des entiers à taille fixe propres à l'implémentation,
soit les fabriquer.
tu peux corriger un peu plus proprement en utilisant un cast vers int32_t, ou alors tu peux déclarer ton tableau en int32_t (ce qui te permet d'économiser un peu de place en mémoire, de te débarasser du cast, et en plus c'est un peu plus logique). Il faut probablement ajouter un #include <inttypes.h> inttypes.h, et plus précisément stdint.h, est C99. Donc, pas C++, sauf
à utiliser la bibliothèque Boost (cstdint.hpp). Sinon, il faut donc soit utiliser des entiers à taille fixe propres à l'implémentation, soit les fabriquer.
-- Pierre Maurette
Antoine Leca
En news:, alian va escriure:
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF;
unsigned long, à tout le moins. Tu ne veux *pas* de propagation de signe...
À quoi sert ce (long) ? crc32tab est un unsigned long, et c'est exactement ce que l'on veut ici, une valeur *non* signée.
À l'intérieur des crochets, nous voulons obtenir une valeur entre 0 et 255. *buf devrait (si les choses étaient intelligement faites) être un unsigned char, donc être étendu à unsigned long pour faire l'opération ^ ; le résultat sera ensuite réduit par le masque 0xFF à l'intervalle désiré, tout va bien de ce côté-là.
Et si long est sur 48 bits, me diriez-vous ? et bien pas de souci, comme les propriétés de l'arithmétique non signée ne se propagent pas en dehors de son domaine de définition pour les opérations comme ^ ou >>.
buf++; len--; } }
Le (long) vient me mettre la grouille et j'ai aucune idee comment corriger ca.
Peut être en l'enlevant ?
Voici le programme de test complet, a compiler avec juste g++ monfichier.c, a tester avec ./a.out monmot :
#include <iostream> using namespace std;
Hmmm...
static const unsigned long crc32tab[256] = {
Un bon point : crc32tab est un unsigned long...
long Signed_CRC32(
Pourquoi retourner un signed long ? C'est quoi, un CRC32 négatif ?
const char *buf, size_t len) {
J'espère pour toi que char est garanti pur porc non signé, parce que sinon, cela va mettre encore plus le désordre...
long crc = 0xFFFFFFFF;
unsigned long, j'espère avoir été clair.
if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab
Et là tu supprimes purement et simplement le transtypage.
Antoine
En news:1143454757.154232.200810@i40g2000cwc.googlegroups.com,
alian va escriure:
J'ai un probleme avec cet algo de calcul de crc32 sur ia64:
long crc = 0xFFFFFFFF;
unsigned long, à tout le moins. Tu ne veux *pas* de propagation de signe...
À quoi sert ce (long) ? crc32tab est un unsigned long, et c'est exactement
ce que l'on veut ici, une valeur *non* signée.
À l'intérieur des crochets, nous voulons obtenir une valeur entre 0 et 255.
*buf devrait (si les choses étaient intelligement faites) être un unsigned
char, donc être étendu à unsigned long pour faire l'opération ^ ; le
résultat sera ensuite réduit par le masque 0xFF à l'intervalle désiré, tout
va bien de ce côté-là.
Et si long est sur 48 bits, me diriez-vous ? et bien pas de souci, comme les
propriétés de l'arithmétique non signée ne se propagent pas en dehors de son
domaine de définition pour les opérations comme ^ ou >>.
buf++; len--; }
}
Le (long) vient me mettre la grouille et j'ai aucune idee comment
corriger ca.
Peut être en l'enlevant ?
Voici le programme de test complet, a compiler avec juste g++
monfichier.c, a tester avec ./a.out monmot :
#include <iostream>
using namespace std;
Hmmm...
static const unsigned long crc32tab[256] = {
Un bon point : crc32tab est un unsigned long...
long Signed_CRC32(
Pourquoi retourner un signed long ? C'est quoi, un CRC32 négatif ?
const char *buf, size_t len) {
J'espère pour toi que char est garanti pur porc non signé, parce que sinon,
cela va mettre encore plus le désordre...
long crc = 0xFFFFFFFF;
unsigned long, j'espère avoir été clair.
if (buf != NULL) {
while (len > 0) {
crc = (crc >> 8) ^ ((long) crc32tab
Et là tu supprimes purement et simplement le transtypage.
À quoi sert ce (long) ? crc32tab est un unsigned long, et c'est exactement ce que l'on veut ici, une valeur *non* signée.
À l'intérieur des crochets, nous voulons obtenir une valeur entre 0 et 255. *buf devrait (si les choses étaient intelligement faites) être un unsigned char, donc être étendu à unsigned long pour faire l'opération ^ ; le résultat sera ensuite réduit par le masque 0xFF à l'intervalle désiré, tout va bien de ce côté-là.
Et si long est sur 48 bits, me diriez-vous ? et bien pas de souci, comme les propriétés de l'arithmétique non signée ne se propagent pas en dehors de son domaine de définition pour les opérations comme ^ ou >>.
buf++; len--; } }
Le (long) vient me mettre la grouille et j'ai aucune idee comment corriger ca.
Peut être en l'enlevant ?
Voici le programme de test complet, a compiler avec juste g++ monfichier.c, a tester avec ./a.out monmot :
#include <iostream> using namespace std;
Hmmm...
static const unsigned long crc32tab[256] = {
Un bon point : crc32tab est un unsigned long...
long Signed_CRC32(
Pourquoi retourner un signed long ? C'est quoi, un CRC32 négatif ?
const char *buf, size_t len) {
J'espère pour toi que char est garanti pur porc non signé, parce que sinon, cela va mettre encore plus le désordre...
long crc = 0xFFFFFFFF;
unsigned long, j'espère avoir été clair.
if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab
Et là tu supprimes purement et simplement le transtypage.
Antoine
Antoine Leca
En news:, Pierre Maurette va escriure:
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ? (Le même code, à peine corrigé, doit fonctionner avec sizeof(long)==2, avec des char sur 16 bits, en supposant bien sûr que les données de la trame ont été rangées un octet par byte; mais là je suis d'accord que c'est pour faire joujou.)
Remplacez long par un type à taille fixe de 32 bits.
Et si tu n'en as pas ?
A mon avis en unsigned.
Là oui, cela risque d'aider.
Antoine
En news:mn.db007d6367b0bfd5.31483@laposte.net,
Pierre Maurette <maurettepierre@wanadoo.fr> va escriure:
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64:
long crc = 0xFFFFFFFF;
if (buf != NULL) {
while (len > 0) {
crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) &
0xff]);
buf++;
len--;
}
}
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ?
(Le même code, à peine corrigé, doit fonctionner avec sizeof(long)==2, avec
des char sur 16 bits, en supposant bien sûr que les données de la trame ont
été rangées un octet par byte; mais là je suis d'accord que c'est pour faire
joujou.)
Remplacez long par un type à taille fixe de 32 bits.
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ? (Le même code, à peine corrigé, doit fonctionner avec sizeof(long)==2, avec des char sur 16 bits, en supposant bien sûr que les données de la trame ont été rangées un octet par byte; mais là je suis d'accord que c'est pour faire joujou.)
Remplacez long par un type à taille fixe de 32 bits.
Et si tu n'en as pas ?
A mon avis en unsigned.
Là oui, cela risque d'aider.
Antoine
Blaise Potard
wrote:
Ca marche avec -1 en effet, un cast avec (int) au lieu de (long), et l'utilisation de LIMITED_32 ...
Arf, tu as tout à fait raison, j'avais oublié que le problème d'extension de signe touchait aussi les éléments de ton tableau crc32tab. La solution de mettre un cast à int résout le problème de façon un peu crade (tu supposes implicitement que sizeof int = 32 bits), tu peux corriger un peu plus proprement en utilisant un cast vers int32_t, ou alors tu peux déclarer ton tableau en int32_t (ce qui te permet d'économiser un peu de place en mémoire, de te débarasser du cast, et en plus c'est un peu plus logique). Il faut probablement ajouter un #include <inttypes.h> (mais là on est revenu à la solution de Pierre Maurette, en fait).
Et ia64, oui c'est de l'itanium (4 proc a 2400 et 8Go de Ram, oui ca compile bien :-)
La classe :-)
alian@cpan.org wrote:
Ca marche avec -1 en effet, un cast avec (int) au lieu de (long), et
l'utilisation de LIMITED_32 ...
Arf, tu as tout à fait raison, j'avais oublié que le problème
d'extension de signe touchait aussi les éléments de ton tableau
crc32tab. La solution de mettre un cast à int résout le problème de
façon un peu crade (tu supposes implicitement que sizeof int = 32 bits),
tu peux corriger un peu plus proprement en utilisant un cast vers
int32_t, ou alors tu peux déclarer ton tableau en int32_t (ce qui te
permet d'économiser un peu de place en mémoire, de te débarasser du
cast, et en plus c'est un peu plus logique). Il faut probablement
ajouter un #include <inttypes.h> (mais là on est revenu à la solution de
Pierre Maurette, en fait).
Et ia64, oui c'est de l'itanium (4 proc a 2400 et 8Go de Ram, oui ca
compile bien :-)
Ca marche avec -1 en effet, un cast avec (int) au lieu de (long), et l'utilisation de LIMITED_32 ...
Arf, tu as tout à fait raison, j'avais oublié que le problème d'extension de signe touchait aussi les éléments de ton tableau crc32tab. La solution de mettre un cast à int résout le problème de façon un peu crade (tu supposes implicitement que sizeof int = 32 bits), tu peux corriger un peu plus proprement en utilisant un cast vers int32_t, ou alors tu peux déclarer ton tableau en int32_t (ce qui te permet d'économiser un peu de place en mémoire, de te débarasser du cast, et en plus c'est un peu plus logique). Il faut probablement ajouter un #include <inttypes.h> (mais là on est revenu à la solution de Pierre Maurette, en fait).
Et ia64, oui c'est de l'itanium (4 proc a 2400 et 8Go de Ram, oui ca compile bien :-)
La classe :-)
Pierre Maurette
En news:, Pierre Maurette va escriure:
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ? (Le même code, à peine corrigé, doit fonctionner avec sizeof(long)==2, avec des char sur 16 bits, en supposant bien sûr que les données de la trame ont été rangées un octet par byte; mais là je suis d'accord que c'est pour faire joujou.) Je suis allé un peu vite sans étudier le code (je me promettais de le
faire plus tard). En passant, tu coupe/quote allègrement, et sans marque de coupure. Je répondais en fait sous le commentaire plus qu'au code. Disons que comme un mauvais toubib, je me suis laissé influencer par le diagnostic suggéré par le patient ;-) Et peut-être par crc*32*. Je n'ai jamais codé de crc. J'ai pensé que ça exigeait des "exact width interger".
Remplacez long par un type à taille fixe de 32 bits.
Et si tu n'en as pas ? ...."A mon avis en unsigned. S'il n'existe pas, vous le fabriquez, avec
des #if, les constantes de limits.h, et des typedef."
-- Pierre Maurette
En news:mn.db007d6367b0bfd5.31483@laposte.net,
Pierre Maurette <maurettepierre@wanadoo.fr> va escriure:
Ave,
J'ai un probleme avec cet algo de calcul de crc32 sur ia64:
long crc = 0xFFFFFFFF;
if (buf != NULL) {
while (len > 0) {
crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) &
0xff]);
buf++;
len--;
}
}
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ?
(Le même code, à peine corrigé, doit fonctionner avec sizeof(long)==2, avec
des char sur 16 bits, en supposant bien sûr que les données de la trame ont
été rangées un octet par byte; mais là je suis d'accord que c'est pour faire
joujou.)
Je suis allé un peu vite sans étudier le code (je me promettais de le
faire plus tard). En passant, tu coupe/quote allègrement, et sans
marque de coupure. Je répondais en fait sous le commentaire plus qu'au
code. Disons que comme un mauvais toubib, je me suis laissé influencer
par le diagnostic suggéré par le patient ;-) Et peut-être par crc*32*.
Je n'ai jamais codé de crc. J'ai pensé que ça exigeait des "exact width
interger".
Remplacez long par un type à taille fixe de 32 bits.
Et si tu n'en as pas ?
...."A mon avis en unsigned. S'il n'existe pas, vous le fabriquez, avec
des #if, les constantes de limits.h, et des typedef."
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF; if (buf != NULL) { while (len > 0) { crc = (crc >> 8) ^ ((long) crc32tab[(crc ^ (*buf)) & 0xff]); buf++; len--; } }
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ? (Le même code, à peine corrigé, doit fonctionner avec sizeof(long)==2, avec des char sur 16 bits, en supposant bien sûr que les données de la trame ont été rangées un octet par byte; mais là je suis d'accord que c'est pour faire joujou.) Je suis allé un peu vite sans étudier le code (je me promettais de le
faire plus tard). En passant, tu coupe/quote allègrement, et sans marque de coupure. Je répondais en fait sous le commentaire plus qu'au code. Disons que comme un mauvais toubib, je me suis laissé influencer par le diagnostic suggéré par le patient ;-) Et peut-être par crc*32*. Je n'ai jamais codé de crc. J'ai pensé que ça exigeait des "exact width interger".
Remplacez long par un type à taille fixe de 32 bits.
Et si tu n'en as pas ? ...."A mon avis en unsigned. S'il n'existe pas, vous le fabriquez, avec
des #if, les constantes de limits.h, et des typedef."
-- Pierre Maurette
Antoine Leca
En news:e094er$rkk$, Antoine Leca (moi) va escriure:
En news:, Pierre Maurette va escriure:
A première vue, votre code n'est pas portable, en ce sens qu'il suppose un long de 32 bits, sizeof(long)==4.
Où ?
OK, ça y est, j'ai vu. Le code est trafiqué pour générer une valeur bizarre qui correspond en gros à l'algorithme classique du CRC32, mais transporté en signé en supposant une machine sur 32 bits. Effectivement, le code résultant n'est plus portable.
Remplacez long par un type à taille fixe de 32 bits. A mon avis en unsigned.
Bin, si tu fais cela, tu reviens à l'algorithme normal du CRC32, qui lui *est* portable ;-)
Antoine
En news:e094er$rkk$1@shakotay.alphanet.ch, Antoine Leca (moi) va escriure:
En news:mn.db007d6367b0bfd5.31483@laposte.net,
Pierre Maurette va escriure:
A première vue, votre code n'est pas portable, en ce sens qu'il
suppose un long de 32 bits, sizeof(long)==4.
Où ?
OK, ça y est, j'ai vu. Le code est trafiqué pour générer une valeur bizarre
qui correspond en gros à l'algorithme classique du CRC32, mais transporté en
signé en supposant une machine sur 32 bits. Effectivement, le code résultant
n'est plus portable.
Remplacez long par un type à taille fixe de 32 bits.
A mon avis en unsigned.
Bin, si tu fais cela, tu reviens à l'algorithme normal du CRC32, qui lui
*est* portable ;-)
En news:e094er$rkk$, Antoine Leca (moi) va escriure:
En news:, Pierre Maurette va escriure:
A première vue, votre code n'est pas portable, en ce sens qu'il suppose un long de 32 bits, sizeof(long)==4.
Où ?
OK, ça y est, j'ai vu. Le code est trafiqué pour générer une valeur bizarre qui correspond en gros à l'algorithme classique du CRC32, mais transporté en signé en supposant une machine sur 32 bits. Effectivement, le code résultant n'est plus portable.
Remplacez long par un type à taille fixe de 32 bits. A mon avis en unsigned.
Bin, si tu fais cela, tu reviens à l'algorithme normal du CRC32, qui lui *est* portable ;-)
Antoine
Antoine Leca
En news:e0948e$qog$, Antoine Leca va escriure:
En news:, alian va escriure:
J'ai un probleme avec cet algo de calcul de crc32 sur ia64: long crc = 0xFFFFFFFF;
unsigned long, à tout le moins. Tu ne veux *pas* de propagation de signe...
Au temps pour moi : en fait, l'algorithme a *besoin* des propriétés spécifiques des entiers en complément à 2 sur machine 32 bits....
À quoi sert ce (long) ? crc32tab est un unsigned long, et c'est exactement ce que l'on veut ici, une valeur *non* signée.
Celui-là, par contre, je ne pense pas qu'il soit nécessaire, on doit pouvoir l'enlever. La valeur sera la même, et donc l'effet de l'opération ^ ne changera pas.
Et si long est sur 48 bits, me diriez-vous ? et bien pas de souci, comme les propriétés de l'arithmétique non signée ne se propagent pas en dehors de son domaine de définition pour les opérations comme ^ ou
.
Cela prouve que celui qui a écrit cela n'avait rien compris !
const char *buf, size_t len) {
J'espère pour toi que char est garanti pur porc non signé, parce que sinon, cela va mettre encore plus le désordre...
En fait non, parce qu'après l'opération ^crc (qui est identique en complément à 2), il y a un masque des 8 bits de poids faible, donc que char soit signé ou pas est sans effet.
(ce qui est le cas de l'algorithme initial, d'ailleurs ;-)).
À quoi sert ce (long) ? crc32tab est un unsigned long, et c'est
exactement ce que l'on veut ici, une valeur *non* signée.
Celui-là, par contre, je ne pense pas qu'il soit nécessaire, on doit pouvoir
l'enlever. La valeur sera la même, et donc l'effet de l'opération ^ ne
changera pas.
Et si long est sur 48 bits, me diriez-vous ? et bien pas de souci,
comme les propriétés de l'arithmétique non signée ne se propagent pas
en dehors de son domaine de définition pour les opérations comme ^ ou
.
Cela prouve que celui qui a écrit cela n'avait rien compris !
const char *buf, size_t len) {
J'espère pour toi que char est garanti pur porc non signé, parce que
sinon, cela va mettre encore plus le désordre...
En fait non, parce qu'après l'opération ^crc (qui est identique en
complément à 2), il y a un masque des 8 bits de poids faible, donc que char
soit signé ou pas est sans effet.
(ce qui est le cas de l'algorithme initial, d'ailleurs ;-)).
À quoi sert ce (long) ? crc32tab est un unsigned long, et c'est exactement ce que l'on veut ici, une valeur *non* signée.
Celui-là, par contre, je ne pense pas qu'il soit nécessaire, on doit pouvoir l'enlever. La valeur sera la même, et donc l'effet de l'opération ^ ne changera pas.
Et si long est sur 48 bits, me diriez-vous ? et bien pas de souci, comme les propriétés de l'arithmétique non signée ne se propagent pas en dehors de son domaine de définition pour les opérations comme ^ ou
.
Cela prouve que celui qui a écrit cela n'avait rien compris !
const char *buf, size_t len) {
J'espère pour toi que char est garanti pur porc non signé, parce que sinon, cela va mettre encore plus le désordre...
En fait non, parce qu'après l'opération ^crc (qui est identique en complément à 2), il y a un masque des 8 bits de poids faible, donc que char soit signé ou pas est sans effet.
(ce qui est le cas de l'algorithme initial, d'ailleurs ;-)).
