Discussion :

[bariole]

Bonsoir,


Encore un probleme d'endianness.
En gros, que fait mon programme, il a une suite de structures bien remplies comme il faut, qu'il ecrit dans un fichier les unes a la suite des autres.
Ce ficher sera ensuite relu plus tard.
Donc pas de probleme d'endianness si il reste sur le meme type d'endian. Mais si je mets ce fichier sur une machine big endian, impossible de le relire correctement.

Il faut donc que je le passe en network order.

Or, voila mon probleme, je ne comprends pas, comment passer toute ma struct en network order. Elle contient notamment des char [].

Voici la struct en question:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
 
typedef struct s_toto_info {
    uint32_t start_offset;
    uint32_t size;
    t_MODE MODE;
    t_TYPE TYPE;
    t_LANG LANG;
    t_OS OS;
    mode_t perms;
    char description[256];
} t_toto_info;
 
typedef struct s_toto_index {
    int id;
    char path[MAXPATHLEN];
    struct s_toto_info info;
} t_toto_index;

Comment htonl mon char description[256] our mon char path[MAXPATHLEN] par exemple ?


Merci.

[bariole]

Je pense avoir trouve, je fais quelque chose du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
t_toto_index *toto_ntohl(t_toto_index *src)
{
    uint32_t tmp;
    size_t i;

    src->id = ntohl(src->id);
    src->info.LANG = ntohl(src->info.LANG);
    src->info.MODE = ntohl(src->info.MODE);
    src->info.OS = ntohl(src->info.OS);
    src->info.TYPE = ntohl(src->info.TYPE);
    src->info.size = ntohl(src->info.size);
    src->info.perms = ntohl(src->info.perms);
    src->info.start_offset = ntohl(src->info.start_offset);

    for (i = 0; i < sizeof(src->fullPath); ++i) {
        memcpy(&tmp, src->fullPath + i,sizeof (tmp));
        tmp = ntohl(tmp) ;                                                                                                                                            
        memcpy(src->fullPath + i, &tmp, sizeof (tmp));
    }
    return src;
}

Merci.


EDIT: En fait, ca semble faux. Dites moi ce que vous en pensez.

[diogene]

Cette question d'endian concerne les données codées sur plus d'un byte. Comme chaque élément d'un char [] est sur 1 byte, il suffit de les copier dans l'ordre où ils sont. La question serait différente pour un int[] par exemple, où chaque int du tableau devrait subir la transformation avant copie.

Par contre, tu devrais être attentif à la question de l'alignement des éléments d'une structure si tu es soucieux de la portabilité de ton fichier.

[bariole]

Effectivement, c'est bien ce que je pensais a la base. Tant que c'est moins d'un byte, ya pas de question a se poser. Mais voyant que le comportement de mon programme etait different sur une machine ppc, j'en ai conclu trop rapidement que ca venait de la.

Pour ce qui est de l'alignement, ma struct est attributed packed.


Merci de ton aide en tout cas.

[nicolas.sitbon]

Pour ce qui est de l'alignement, ma struct est attributed packed.

Justement, tu perds en portabilité avec ça, rien ne dit que les environnements qui vont interagir avec ton appli disposent d'un compilateur capable de faire la même chose.

[Mac LAK]

Justement, tu perds en portabilité avec ça, rien ne dit que les environnements qui vont interagir avec ton appli disposent d'un compilateur capable de faire la même chose.

Il est quand même plus que rare qu'un compilateur C, dédié à la base à faire du code bas niveau, ne permette pas d'aligner les structures sur un octet... C'est fréquent dans les langages de haut niveau, mais le C est rarement touché par ce problème.

Même s'il est parfois nécessaire de convertir la structure "machine" vers une structure de haut niveau (=alignée sur des mots machine et/ou convertie en quelque chose de portable, genre texte / XML) pour pouvoir l'utiliser dans d'autres langages...

[diogene]

Il suffit de lire et d'écrire la structure élément par élément et non pas d'un seul bloc pour éviter les problèmes d'alignement différents.

[Emmanuel Delahaye]

Effectivement, c'est bien ce que je pensais a la base. Tant que c'est moins d'un byte, ya pas de question a se poser. Mais voyant que le comportement de mon programme etait different sur une machine ppc, j'en ai conclu trop rapidement que ca venait de la.

Pour ce qui est de l'alignement, ma struct est attributed packed.

Packed ne fonctionne pas sur PowerPC...

Il y a 2 façons de faire des enregistrements portables. Le mode texte (Simple, 98% portable en ASCII, facile à transcoder en EBCDIC pour les 2% restants...) et un mode binaire indépendant de toute architecture (complexe, 100% portable).

[Emmanuel Delahaye]

Il est quand même plus que rare qu'un compilateur C, dédié à la base à faire du code bas niveau, ne permette pas d'aligner les structures sur un octet...

C'est pas une question de compilateur, mais de machine. Un Power PC (et toute machine Freescale en général) ne sait pas adresser un word à une adresse impaire, donc le mode 'packed' n'existe pas sur un compilateur pour Power PC.

Un x86 sait le faire, mais au prix d'un ralentissement, car l'accès se fait en 2 x 8-bit au lieu de 1 x 16-bit.

[Emmanuel Delahaye]

Il suffit de lire et d'écrire la structure élément par élément et non pas d'un seul bloc pour éviter les problèmes d'alignement différents.

Ca ne change rien. Les solutions sont connues et ont été exposées des zillions de fois : texte (CSV, XML etc.) ou binaire indépendant (TLV, BER, XDR ...)

[Mac LAK]

C'est pas une question de compilateur, mais de machine. Un Power PC (et toute machine Freescale en général) ne sait pas adresser un word à une adresse impaire, donc le mode 'packed' n'existe pas sur un compilateur pour Power PC.

Heu... Non.

J'ai des cartes CPU PowerPC qui tournent avec des structures alignées sur un octet, et ça marche très bien, avec du code portable x86 Windows / x86 Linux / PPC sous *nix.
Et vu que c'est du code qui reconstruit "à la main", entre autres, des entêtes IP/UDP et des flux de bits, je peux te garantir que c'est bien aligné à l'octet...

Par contre, j'ai déjà eu la farce (et qui faisait mal) avec des processeurs Sparc, qui sont ultra sensibles à ce niveau... Et encore !! Tant que c'est généré par le compilateur, via une structure par exemple, il se débrouille correctement pour éviter les Bus Error. Par contre, quand on tape "à la main" de façon non alignée, ça explose.

De façon générale, tout dépend du compilateur, s'il génère (ou non !) le code requis pour passer les barrières d'alignement... C'est TOUJOURS le cas avec les structures / unions, ça ne l'est jamais par contre pour un flux lu n'importe comment.

[Emmanuel Delahaye]

Heu... Non.

J'ai des cartes CPU PowerPC qui tournent avec des structures alignées sur un octet, et ça marche très bien, avec du code portable x86 Windows / x86 Linux / PPC sous *nix.

Oui, effectivement, ça dépend si on câble ou non le fil de séparation de octets hauts et bas (dont j'ai oublié le nom). Sur les architectures que j'utilisais en télecom, il n'était pas cablé, donc impossible d'adresser un word à une adresse impaire... (BERR)

[Médinoc]

Cela me rappelle la macro UNALIGNED sous Visual, qui sert justement à dire au compilateur de faire la cuisine nécessaire...