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 :
Visiblement, ce code ne vient pas du PO, et je ne crois pas que le but ici soit de discuter de la validité du calcul effectué, mais d'obtenir les mêmes résultats qu'un algo existant, pour des soucis de compatibilité.
En fait la Unsigned_CRC32 fonctionne deja ... Et la Signed est la pour des histoire de compatibilites avec une fonction PHP qui demande un signed ... Brrrr. Il vaut mieux pas savoir. Ca a l'air treeees D'ailleurs cette machine itanium s'appelle Vador, un hasard ?
Visiblement, ce code ne vient pas du PO, et je ne crois pas que le but
ici soit de discuter de la validité du calcul effectué, mais d'obtenir
les mêmes résultats qu'un algo existant, pour des soucis de
compatibilité.
En fait la Unsigned_CRC32 fonctionne deja ... Et la Signed est la pour des
histoire de compatibilites avec une fonction PHP qui demande un signed ...
Brrrr. Il vaut mieux pas savoir. Ca a l'air treeees mal@. D'ailleurs cette
machine itanium s'appelle Vador, un hasard ?
Visiblement, ce code ne vient pas du PO, et je ne crois pas que le but ici soit de discuter de la validité du calcul effectué, mais d'obtenir les mêmes résultats qu'un algo existant, pour des soucis de compatibilité.
En fait la Unsigned_CRC32 fonctionne deja ... Et la Signed est la pour des histoire de compatibilites avec une fonction PHP qui demande un signed ... Brrrr. Il vaut mieux pas savoir. Ca a l'air treeees D'ailleurs cette machine itanium s'appelle Vador, un hasard ?
Vincent Lefevre
Dans l'article , Pierre Maurette écrit:
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.
Déjà, le code est buggé avec des long de 32 bits.
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.
Dans l'article <mn.db007d6367b0bfd5.31483@laposte.net>,
Pierre Maurette <maurettepierre@wanadoo.fr> écrit:
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.
Déjà, le code est buggé avec des long de 32 bits.
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.
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.
Déjà, le code est buggé avec des long de 32 bits.
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.
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...
Visiblement, ce code ne vient pas du PO, et je ne crois pas que le but ici soit de discuter de la validité du calcul effectué, mais d'obtenir les mêmes résultats qu'un algo existant, pour des soucis de compatibilité.
Certes. Cependant, il faut dire que lorsque le message commence par ::: algo de calcul de crc32 il est permis de se tromper et de supposer que le but de l'algorithme (décrit nulle part) est de calculer « un CRC sur 32 bits ». Au temps pour moi donc, comme je l'écrivais.
Après, par exemple en relisant le fil aujourd'hui, on comprend mieux ; surtout lorsqu'on apprend que ::: En fait la Unsigned_CRC32 fonctionne deja ... ;-)
Pour en revenir à l'algorithme initial, il n'est pas portable tel quel en dehors d'une machine 16 ou 32 bits en complément à 2 avec l'implémentation classique de >> ; et la « solution » que vous avez trouvé pour résoudre ce problème, est de rester bien tranquillement dans ce cadre bien sécurisant.
Mais est-ce la meilleure chose à faire ? Est-ce que Alian a compris pourquoi cela fonctionnait (ce qui était un des buts du fil) ?
C'est sûr qu'avec des unsigned, tout devient plus simple!
Pas du tout. Cela devient plus *clair*, ou plus portable. Par contre, je concède que les performances seront moins bonnes.
Qu'est-ce que donne (désolé, je n'ai pas de jeu d'essai) :
/* NON TESTÉ */
long Signed_CRC32(const unsigned char *tab, size_t lg) { unsigned long long crc = 0xFFFFFFFF;
crc >>= 8; if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */ crc ^= crc32tab[indice]; }
return crc^0xFFFFFFFF; }
La ligne avec le commentaire représente la perte de performances pour ne _pas_ utiliser les propriétés spécifiques de l'architecture (ici l'opération
sur des nombres négatifs). Le reste des changements n'est que du comestique (ou des erreurs de ma part).
long long, c'est pour être bien sûr que l'on va utiliser des registres sur 64 bits, /donc/ être portable sur une architecture 64 bits.
Antoine
En news:e099kl$gb1$1@arcturus.ciril.fr, Blaise Potard va escriure:
Antoine Leca wrote:
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...
Visiblement, ce code ne vient pas du PO, et je ne crois pas que le but
ici soit de discuter de la validité du calcul effectué, mais d'obtenir
les mêmes résultats qu'un algo existant, pour des soucis de
compatibilité.
Certes. Cependant, il faut dire que lorsque le message commence par
::: algo de calcul de crc32
il est permis de se tromper et de supposer que le but de l'algorithme
(décrit nulle part) est de calculer « un CRC sur 32 bits ».
Au temps pour moi donc, comme je l'écrivais.
Après, par exemple en relisant le fil aujourd'hui, on comprend mieux ;
surtout lorsqu'on apprend que
::: En fait la Unsigned_CRC32 fonctionne deja ...
;-)
Pour en revenir à l'algorithme initial, il n'est pas portable tel quel en
dehors d'une machine 16 ou 32 bits en complément à 2 avec l'implémentation
classique de >> ; et la « solution » que vous avez trouvé pour résoudre ce
problème, est de rester bien tranquillement dans ce cadre bien sécurisant.
Mais est-ce la meilleure chose à faire ? Est-ce que Alian a compris pourquoi
cela fonctionnait (ce qui était un des buts du fil) ?
C'est sûr qu'avec des unsigned, tout devient plus simple!
Pas du tout. Cela devient plus *clair*, ou plus portable.
Par contre, je concède que les performances seront moins bonnes.
Qu'est-ce que donne (désolé, je n'ai pas de jeu d'essai) :
/* NON TESTÉ */
long Signed_CRC32(const unsigned char *tab, size_t lg) {
unsigned long long crc = 0xFFFFFFFF;
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...
Visiblement, ce code ne vient pas du PO, et je ne crois pas que le but ici soit de discuter de la validité du calcul effectué, mais d'obtenir les mêmes résultats qu'un algo existant, pour des soucis de compatibilité.
Certes. Cependant, il faut dire que lorsque le message commence par ::: algo de calcul de crc32 il est permis de se tromper et de supposer que le but de l'algorithme (décrit nulle part) est de calculer « un CRC sur 32 bits ». Au temps pour moi donc, comme je l'écrivais.
Après, par exemple en relisant le fil aujourd'hui, on comprend mieux ; surtout lorsqu'on apprend que ::: En fait la Unsigned_CRC32 fonctionne deja ... ;-)
Pour en revenir à l'algorithme initial, il n'est pas portable tel quel en dehors d'une machine 16 ou 32 bits en complément à 2 avec l'implémentation classique de >> ; et la « solution » que vous avez trouvé pour résoudre ce problème, est de rester bien tranquillement dans ce cadre bien sécurisant.
Mais est-ce la meilleure chose à faire ? Est-ce que Alian a compris pourquoi cela fonctionnait (ce qui était un des buts du fil) ?
C'est sûr qu'avec des unsigned, tout devient plus simple!
Pas du tout. Cela devient plus *clair*, ou plus portable. Par contre, je concède que les performances seront moins bonnes.
Qu'est-ce que donne (désolé, je n'ai pas de jeu d'essai) :
/* NON TESTÉ */
long Signed_CRC32(const unsigned char *tab, size_t lg) { unsigned long long crc = 0xFFFFFFFF;
crc >>= 8; if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */ crc ^= crc32tab[indice]; }
return crc^0xFFFFFFFF; }
La ligne avec le commentaire représente la perte de performances pour ne _pas_ utiliser les propriétés spécifiques de l'architecture (ici l'opération
sur des nombres négatifs). Le reste des changements n'est que du comestique (ou des erreurs de ma part).
long long, c'est pour être bien sûr que l'on va utiliser des registres sur 64 bits, /donc/ être portable sur une architecture 64 bits.
Antoine
Blaise Potard
Antoine Leca wrote:
Pour en revenir à l'algorithme initial, il n'est pas portable tel quel en dehors d'une machine 16 ou 32 bits en complément à 2 avec l'implémentation classique de >> ; et la « solution » que vous avez trouvé pour résoudre ce problème, est de rester bien tranquillement dans ce cadre bien sécurisant.
C'était effectivement plus un vulgaire hack qu'autre chose.
C'est sûr qu'avec des unsigned, tout devient plus simple!
Pas du tout. Cela devient plus *clair*, ou plus portable.
Oui, je voulais dire qu'il était nettement plus facile d'avoir un programme portable avec un calcul de crc sur des unsigned.
Par contre, je concède que les performances seront moins bonnes.
Qu'est-ce que donne (désolé, je n'ai pas de jeu d'essai) :
Ça marche, ça donne en 64-bits exactement le même résultat que la version 32-bits.
/* NON TESTÉ */
long Signed_CRC32(const unsigned char *tab, size_t lg) { unsigned long long crc = 0xFFFFFFFF;
crc >>= 8; if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */ crc ^= crc32tab[indice]; }
return crc^0xFFFFFFFF; }
Antoine Leca wrote:
Pour en revenir à l'algorithme initial, il n'est pas portable tel quel en
dehors d'une machine 16 ou 32 bits en complément à 2 avec l'implémentation
classique de >> ; et la « solution » que vous avez trouvé pour résoudre ce
problème, est de rester bien tranquillement dans ce cadre bien sécurisant.
C'était effectivement plus un vulgaire hack qu'autre chose.
C'est sûr qu'avec des unsigned, tout devient plus simple!
Pas du tout. Cela devient plus *clair*, ou plus portable.
Oui, je voulais dire qu'il était nettement plus facile d'avoir un
programme portable avec un calcul de crc sur des unsigned.
Par contre, je concède que les performances seront moins bonnes.
Qu'est-ce que donne (désolé, je n'ai pas de jeu d'essai) :
Ça marche, ça donne en 64-bits exactement le même résultat que la
version 32-bits.
/* NON TESTÉ */
long Signed_CRC32(const unsigned char *tab, size_t lg) {
unsigned long long crc = 0xFFFFFFFF;
Pour en revenir à l'algorithme initial, il n'est pas portable tel quel en dehors d'une machine 16 ou 32 bits en complément à 2 avec l'implémentation classique de >> ; et la « solution » que vous avez trouvé pour résoudre ce problème, est de rester bien tranquillement dans ce cadre bien sécurisant.
C'était effectivement plus un vulgaire hack qu'autre chose.
C'est sûr qu'avec des unsigned, tout devient plus simple!
Pas du tout. Cela devient plus *clair*, ou plus portable.
Oui, je voulais dire qu'il était nettement plus facile d'avoir un programme portable avec un calcul de crc sur des unsigned.
Par contre, je concède que les performances seront moins bonnes.
Qu'est-ce que donne (désolé, je n'ai pas de jeu d'essai) :
Ça marche, ça donne en 64-bits exactement le même résultat que la version 32-bits.
/* NON TESTÉ */
long Signed_CRC32(const unsigned char *tab, size_t lg) { unsigned long long crc = 0xFFFFFFFF;
crc >>= 8; if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */ crc ^= crc32tab[indice]; }
return crc^0xFFFFFFFF; }
James Kanze
Antoine Leca wrote:
En news:, Pierre Maurette va escriure:
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ù ?
crc >> 8
Si la taille d'un long est 32 bits, la valeur initiale de crc est négative, et le résultat d'un >> sur une valeur négative dépend de l'implémentation.
En règle générale, quand on manipule les bits comme ici, les types unsigned sont préférables. Pour des choses comme les CRC, j'utilise normalement uint32_t et al.
(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 ?
L'algorithme ici ne marche pas ? (En fait, je crois que les bits supplémentaires de poids forts seront toujours 0, et que donc, l'algorithme marchera quand même. Mais il y a des algorithmes semblables où c'est moins évidents.)
A mon avis en unsigned.
Là oui, cela risque d'aider.
C'est même essentiel, je crois.
-- James Kanze 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
Antoine Leca wrote:
En news:mn.db007d6367b0bfd5.31483@laposte.net,
Pierre Maurette <maurettepierre@wanadoo.fr> va escriure:
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ù ?
crc >> 8
Si la taille d'un long est 32 bits, la valeur initiale de crc
est négative, et le résultat d'un >> sur une valeur négative
dépend de l'implémentation.
En règle générale, quand on manipule les bits comme ici, les
types unsigned sont préférables. Pour des choses comme les CRC,
j'utilise normalement uint32_t et al.
(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 ?
L'algorithme ici ne marche pas ? (En fait, je crois que les bits
supplémentaires de poids forts seront toujours 0, et que donc,
l'algorithme marchera quand même. Mais il y a des algorithmes
semblables où c'est moins évidents.)
A mon avis en unsigned.
Là oui, cela risque d'aider.
C'est même essentiel, je crois.
--
James Kanze kanze.james@neuf.fr
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
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ù ?
crc >> 8
Si la taille d'un long est 32 bits, la valeur initiale de crc est négative, et le résultat d'un >> sur une valeur négative dépend de l'implémentation.
En règle générale, quand on manipule les bits comme ici, les types unsigned sont préférables. Pour des choses comme les CRC, j'utilise normalement uint32_t et al.
(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 ?
L'algorithme ici ne marche pas ? (En fait, je crois que les bits supplémentaires de poids forts seront toujours 0, et que donc, l'algorithme marchera quand même. Mais il y a des algorithmes semblables où c'est moins évidents.)
A mon avis en unsigned.
Là oui, cela risque d'aider.
C'est même essentiel, je crois.
-- James Kanze 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
James Kanze
Pierre Maurette wrote:
[...]
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.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc, stdint.h est standard (et Boost risque de ne pas marcher du tout).
-- James Kanze 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
Pierre Maurette wrote:
[...]
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.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc,
stdint.h est standard (et Boost risque de ne pas marcher du
tout).
--
James Kanze kanze.james@neuf.fr
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
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.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc, stdint.h est standard (et Boost risque de ne pas marcher du tout).
-- James Kanze 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
Pierre Maurette
Pierre Maurette wrote:
[...]
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.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc, stdint.h est standard (et Boost risque de ne pas marcher du tout). La question posée était certes pertinente ici. Néanmoins le PO est en
C++ :
<CIT> Voici le programme de test complet, a compiler avec juste g++ monfichier.c, a tester avec ./a.out monmot :
int main(int argc, char** argv) { std::string param(argv[1]); long value = Signed_CRC32(param.c_str(), param.size()); printf("O=%lXn", value); } </CIT>
-- Pierre Maurette
Pierre Maurette wrote:
[...]
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.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc,
stdint.h est standard (et Boost risque de ne pas marcher du
tout).
La question posée était certes pertinente ici. Néanmoins le PO est en
C++ :
<CIT>
Voici le programme de test complet, a compiler avec juste g++
monfichier.c, a tester avec ./a.out monmot :
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.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc, stdint.h est standard (et Boost risque de ne pas marcher du tout). La question posée était certes pertinente ici. Néanmoins le PO est en
C++ :
<CIT> Voici le programme de test complet, a compiler avec juste g++ monfichier.c, a tester avec ./a.out monmot :
int main(int argc, char** argv) { std::string param(argv[1]); long value = Signed_CRC32(param.c_str(), param.size()); printf("O=%lXn", value); } </CIT>
-- Pierre Maurette
Vincent Lefevre
Dans l'article <e0c457$3bp$, James Kanze écrit:
Sauf qu'ici, on parle justement du C, et non du C++. Et donc, stdint.h est standard (et Boost risque de ne pas marcher du tout).
Sauf que rigoureusement, c'est <stdint.h> et non stdint.h; enfin, la norme met les chevrons partout, sauf dans l'index, pour une raison technique je suppose.
Dans l'article <e0c457$3bp$1@emma.aioe.org>,
James Kanze <kanze.james@neuf.fr> écrit:
Sauf qu'ici, on parle justement du C, et non du C++. Et donc,
stdint.h est standard (et Boost risque de ne pas marcher du
tout).
Sauf que rigoureusement, c'est <stdint.h> et non stdint.h; enfin, la
norme met les chevrons partout, sauf dans l'index, pour une raison
technique je suppose.
Sauf qu'ici, on parle justement du C, et non du C++. Et donc, stdint.h est standard (et Boost risque de ne pas marcher du tout).
Sauf que rigoureusement, c'est <stdint.h> et non stdint.h; enfin, la norme met les chevrons partout, sauf dans l'index, pour une raison technique je suppose.
crc >>= 8; if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */ crc ^= crc32tab[indice]; }
return crc^0xFFFFFFFF; }
Si j'ai bien compris, tu peux retourner une valeur qui n'est pas représentable dans un long. Il faudrait tester si c'est > LONG_MAX et renvoyer la valeur négative correspondante si ce n'est pas le cas.
long long, c'est pour être bien sûr que l'on va utiliser des registres sur 64 bits, /donc/ être portable sur une architecture 64 bits.
Je ne comprends pas pourquoi un unsigned long ne suffirait pas, puisque le CRC reste sur 32 bits.
crc >>= 8;
if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */
crc ^= crc32tab[indice];
}
return crc^0xFFFFFFFF;
}
Si j'ai bien compris, tu peux retourner une valeur qui n'est pas
représentable dans un long. Il faudrait tester si c'est > LONG_MAX
et renvoyer la valeur négative correspondante si ce n'est pas le
cas.
long long, c'est pour être bien sûr que l'on va utiliser des registres sur
64 bits, /donc/ être portable sur une architecture 64 bits.
Je ne comprends pas pourquoi un unsigned long ne suffirait pas,
puisque le CRC reste sur 32 bits.
crc >>= 8; if(crc&0x00800000) crc|=0xFF000000; /* effet de signed >> */ crc ^= crc32tab[indice]; }
return crc^0xFFFFFFFF; }
Si j'ai bien compris, tu peux retourner une valeur qui n'est pas représentable dans un long. Il faudrait tester si c'est > LONG_MAX et renvoyer la valeur négative correspondante si ce n'est pas le cas.
long long, c'est pour être bien sûr que l'on va utiliser des registres sur 64 bits, /donc/ être portable sur une architecture 64 bits.
Je ne comprends pas pourquoi un unsigned long ne suffirait pas, puisque le CRC reste sur 32 bits.
