Le problème du jour

Bonjour à tous,

Voici un petit problème qui m'arrive...
Tout d'abord le contexte : jusque là, je travaillais sous MacOsX avec un G5. Mon application fonctionnait parfaitement (Du moins, sans bug). Pour certaines raisons, indépendantes de ma volonté, je me retrouve, toujours sous MacOsX, mais avec un iMac et un processeur Intel...

Voilà un extrait de code :

Code:

---

1 2 3 4 5 6 7 8

guint32 chunkSize; int n; n += fread(&chunkSize, 4, 1, file); if (chunkSize < 0) printf ("chunkSize < 0 (%d)\n", chunkSize); else printf("chunkSize >= 0 (%d)\n", chunkSize);

---

En gros, je parcours un fichier et lit un entier que je place dans "chunkSize". ("file" est de type FILE* et est correctement ouvert, etc...)
guint32 est un type de la bibliothèque "GLib" (cf. http://developer.gnome.org/doc/API/2...s.html#guint32)

Sur ma première machine (G5) tout allait parfaitement bien dans le meilleur des mondes, cependant, sur le Mac-Intel voilà ce que me retourne le "printf" :

Code:

---

1 2	chunkSize >= 0 (-1308622848)

---

Bon, j'ai tout de suite penser à un problème big/little endian (et je pense toujours que c'est lié à cela)... Cependant, je suis perplexe sur l'affichage du printf : Le programme détecte que chunkSize est positif, cependant à l'affichage il est négatif...

Qu'en pensez-vous ?

Pour moi, un guint32 n'est jamais négatif... Je suis surpris que ton compilateur ne t'ait pas donné de warning...
Donc, oui, c'est bien un problème d'endianness.

Par chance, les fichiers existants sont enregistrés en BigEndian, ce qui est le format dit "réseau". Tu peux donc corriger le code pour employer les fonctions htonl() avant écriture et ntohl() après lecture.

Ok, merci. Je vais voir cela.
J'oubliais de préciser une petite chose : le fichier que j'essaie de lire sur le Mac-Intel a été écrit sur le G5...

Heureusement.
Dans l'autre sens, le fichier serait en Little-Endian et ce serait plus compliqué à corriger.

En modifiant le programme, le format du fichier ne changera pas, et la lecture sera adaptée aux deux plate-formes.

Citation:

---

Envoyé par Médinoc

Heureusement.
Dans l'autre sens, le fichier serait en Little-Endian et ce serait plus compliqué à corriger.

En modifiant le programme, le format du fichier ne changera pas, et la lecture sera adaptée aux deux plate-formes.

---

L'endiannes est une chose, la largeur des types pourrait en être une autre... La compatibilité des données binaires ne se règle pas aussi simplement que ça.

Soit on utilise un format indépendant comme BER ou XDR, par exemple (euh, bon courage...), soit on passe en mode texte (ASCII, par exemple), ce qui est le plus simple.

Salut,

Ton printf en %d n'interprete-t-il pas ta valeur comme une valeur signée ?
Ne faudrait-il pas utiliser %u ?

A+

Sachant que le type contient "32", je suppose que sa longueur est étudiée pour être toujours 32 bits selon la plate-forme...
Et puis, ça reste sur du MacOS.

Par contre, la taille devrait être sizeof(chunkSize) et non 4...

Puisque tu utilises la glib, il existe la macro GUINT32_SWAP_LE_BE() (voir http://developer.gnome.org/doc/API/2...WAP-LE-BE:CAPS) permet de réaliser la conversion little-endian/big-endian dans les deux sens. Comme guint32 est conçu pour être portable, je pense que tu devrais parvenir à résoudre tes problèmes avec la doc. Bonne chance!

Thierry

Sauf que là, le fichier est TOUJOURS en Big-Endian.
Il faudrait donc utiliser GUINT32_FROM_BE et GUINT32_TO_BE et non pas SWAP...

Bonjour,

Citation:

---

Envoyé par Fabllot

Voilà un extrait de code :

Code:

---

1 2 3 4 5

guint32 chunkSize; int n; n += fread(&chunkSize, 4, 1, file); ...

---

Qu'en pensez-vous ?

---

J'en pense que tu as eu de la chance que ça marche jusqu'à présent

Tu ajoutes une valeur à une variable non initialisée, et tu utilises le résultat sans te poser de question.

Un de mes élèves écrirait ça, il se ferait taper sur les doigts (symboliquement, bien sûr)

Citation:

---

Envoyé par thewho

Un de mes élèves écrirait ça, il se ferait taper sur les doigts (symboliquement, bien sûr)

---

Pourquoi symboliquement ? ;)
J'avais un prof de maths qui nous disait (en plaisantant bien sûr) :

Citation:

---

Envoyé par le prof de maths psychopathe

Je vais faire entrer ça dans vos têtes à coups de batte de baseball !

---

Ca marchait bien comme technique !:mouarf:

Citation:

---

Envoyé par le prof de maths psychopathe

Je vais faire entrer ça dans vos têtes à coups de batte de baseball !

---

http://nounours.bleublog.ch/files/im...1148470048.jpg

Citation:

---

Envoyé par thewho

J'en pense que tu as eu de la chance que ça marche jusqu'à présent
Tu ajoutes une valeur à une variable non initialisée, et tu utilises le résultat sans te poser de question.

---

En fait, j'ai réduit le code au minimum pour se concentrer sur le problème BE / LE ... La valeur de "n" est bien initialisé dans mon code...

Citation:

---

Envoyé par mujigka

Puisque tu utilises la glib, il existe la macro GUINT32_SWAP_LE_BE() (voir http://developer.gnome.org/doc/API/2...WAP-LE-BE:CAPS) permet de réaliser la conversion little-endian/big-endian dans les deux sens. Comme guint32 est conçu pour être portable, je pense que tu devrais parvenir à résoudre tes problèmes avec la doc. Bonne chance!

---

Merci pour cette info, cela me parait interressant. Je vais y regarder de plus près.

Merci à tous pour vos remarques.

Citation:

---

Envoyé par Médinoc

Sauf que là, le fichier est TOUJOURS en Big-Endian.
Il faudrait donc utiliser GUINT32_FROM_BE et GUINT32_TO_BE et non pas SWAP...

---

Si il passe sur une architecture INTEL, il ne passe pas en little-endian comme avec les processeurs x86? Je ne connais pas le processeur du iMac en question...

Thierry

Citation:

---

Envoyé par Médinoc

Sauf que là, le fichier est TOUJOURS en Big-Endian.

---

J'ai jamais parlé du proc...

Et justement, c'est à ça que sert la macro: Passer d'un GUINT32 au format "processeur" à un GUINT32 au format "Fichier toujours en Big-Endian", et inversement pour l'autre macro...

Citation:

---

Envoyé par Médinoc

J'ai jamais parlé du proc...

Et justement, c'est à ça que sert la macro: Passer d'un GUINT32 au format "processeur" à un GUINT32 au format "Fichier toujours en Big-Endian", et inversement pour l'autre macro...

---

C'est pareil que les hton*(), ntoh*(), non ?

Oui, mais ce n'est pas la même bibliothèque (glib contre "???" sous unixoïde, Winsock2 sous Windows), et ça fournit aussi des macros pour forcer en little-endian quel que soit la machine, ce qui n'est jamais proposé par les ?to??().

En fait, mon "seg fault", ne venait pas de du probleme BE/LE, mais d'une "astuce" de programmation (pas très conformiste) que mon nouveau compilateur ne gerait pas bien... Bref, on est repassé à du code propre (mais plus très clair) et ça refonctionne.

Pour mes fichiers, je me suis pas trop pris la tête pour le moment, et je les ai regénérés directement sur mon Mac-Intel, commecela pas de soucis. Et quand viendra le moment, où je devrais voir pour la portabilité, j'utiliserais sans doute les macros de glib qui semblent bien pratique.
Cependant, comme je réalise pour le moment, seulement une maquette, la portabilité n'est pas une priorité...

Merci à tous.

Citation:

---

Envoyé par Fabllot

Cependant, comme je réalise pour le moment, seulement une maquette, la portabilité n'est pas une priorité...

---

Ben voyons... Il sera toujours temps de tout casser pour tout refaire... Tu as une idée de ce que ça coute ?

La plupart des explosions de budgets (temps, argent) sur les projets sont le résultat de mauvaises spécifications et de mauvaises conceptions...

Citation:

---

Envoyé par Fabllot

En fait, mon "seg fault", ne venait pas de du probleme BE/LE, mais d'une "astuce" de programmation (pas très conformiste) que mon nouveau compilateur ne gerait pas bien... Bref, on est repassé à du code propre (mais plus très clair) et ça refonctionne.

Pour mes fichiers, je me suis pas trop pris la tête pour le moment, et je les ai regénérés directement sur mon Mac-Intel, commecela pas de soucis. Et quand viendra le moment, où je devrais voir pour la portabilité, j'utiliserais sans doute les macros de glib qui semblent bien pratique.
Cependant, comme je réalise pour le moment, seulement une maquette, la portabilité n'est pas une priorité...

Merci à tous.

---

C'est un projet personnel? Cette attitude n'est sans doute pas recommandable du point de vue d'un projet industriel où les erreurs de conceptions se paient assez cher.

Thierry