Discussion :

[cirdan_elf]

Bonjour,

je reçois par le réseau des données, je vais avoir par exemple un entier sur 4 octets, stocké dans un buffer.

le code suivant est-il toujours correct ?

Code :

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

1
2
3
4
5
unsigned char buffer[100];
 
/* buffer[1..4] va contenir mon entier */
 
int n = *((int *)&buffer[1]); /* je suppose que sizeof(int) == 4, et je me fous de l'endianness, l'important n'est pas là */

Je pense que ce n'est pas correct. A cause du fait que &buffer[1] n'est pas forcément correctement placé en mémoire pour pointer vers un int, et qu'il faut faire :

Code :

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

memcpy(&n, &buffer[1], 4);

ou

Code :

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

n = buffer[1] * ? + buffer[2] * ? + etc...

J'ai raison ou pas ?

[ram-0000]

Tu as sacrément intérêt à être sûr de toi (données reçues, boutisme des données reçues), mais je suppose que c'est ton problème.

L'autre problème que tu risque d'avoir est un problème d'alignement mémoire. &buffer[1] va être une adresse impaire et suivant les machines, le déréférencement d'un pointeur impair va soit prendre du temps (génération des cycles intermédiaires pour lire une adresse non correctement alignée) soit générer une erreur sur le bus.

Donc la solution de copie me parait la plus sûre :

Code :

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

memcpy(&n, &buffer[1], 4);

[cirdan_elf]

L'autre problème que tu risque d'avoir est un problème d'alignement mémoire. &buffer[1] va être une adresse impaire et suivant les machines, le déréférencement d'un pointeur impair va soit prendre du temps (génération des cycles intermédiaires pour lire une adresse non correctement alignée) soit générer une erreur sur le bus.

C'est ce à quoi je pensais, je voulais une confirmation.

Merci.

[Mac LAK]

Je te confirme un point en tout cas : sur une machine à base de processeur Sparc (Sun), ton code initial provoquera systématiquement un arrêt du programme avec un "Bus Error"...

Sur un x86, le cast "bourrin" marchera, ainsi que sur beaucoup de processeurs. Mais il existe d'autres processeurs qui, eux, ne supporteront pas ce genre de copie non alignée.

Le "memcpy" est garanti fonctionnel, mais le remplissage de ton entier octet par octet n'est pas forcément garanti. "memcpy" est donc fiable, même si ce n'est pas (forcément) la solution la plus rapide possible sur certains processeurs.

[cirdan_elf]

le remplissage de ton entier octet par octet n'est pas forcément garanti

Comment ça ?

[Mac LAK]

Il est possible que la lecture de ton octet force une lecture "int" non alignée de par la nature de la variable de destination. Peu probable, certes, mais possible malgré tout (et donc dangereux).

Il faudrait utiliser plusieurs casts, voire variables temporaires, pour garantir que l'affectation d'un octet vers l'entier destination se fait exclusivement via les registres, qui ne sont pas soumis aux contraintes d'alignement.

De façon générale, les lectures non alignées devraient être limitées soit à des accès de champs de structures (gérés par le compilateur), soit à plate-formes connues pour ne PAS avoir de problèmes d'accès non-aligné... Sachant que même sur un x86, un accès non-aligné n'est de toutes façons pas une bonne idée, cela coûte plus de temps CPU qu'un accès aligné.

Normalement, "memcpy" est prévu pour être implémenté au plus efficace, c'est à dire avec le maximum possible d'accès alignés.