Apropos de memcpy

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Apropos de memcpy

dave_tetehi

cat /dev/urandom > /dev/fb0

Bonjour a tous,
je trouve nul part si cet effet de bord est encouragé ou pas par l'iso c99. Z'avez pas une idée par hasard ?

Code :

#include <stdio.h>
#include <string.h>
int main()
{
int i;
int t[100];
t[0] = 0, t[1] = 1, t[2] = 2, t[3] = 3;
memcpy(t+4, t, 96*sizeof(int));
for(i=0; i < 30; i++)
printf("%d", t[i]);
printf("...\n" );
return 0;
}

Message cité 1 fois

Publicité

Elmoricq

Modérateur

Quel effet de bord ?

Je ne vois rien d'anormal dans le comportement que tu constates...

morph

extrait du man de memcpy

DESCRIPTION
The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas should not overlap. Use memmove(3) if the memory areas do overlap.

tpierron

C'est très casse gueule ce que tu fais. J'imagine que de la sorte tu répètes la valeur des 4 premiers entiers sur tout le tableau. Si c'est vraiment ce que tu veux, utilises une fonction dédiée, car tu n'as aucune garantie que ça fonctionne ailleurs (bien que ça puisse ne ppas t'intéresser).

Toujours est-il que pour éviter des prises de tête assez sévères, utilise des comportements documentés, parce que le jour où ça va foirer, c'est le genre de code que tu ne soupçonneras pas et passera des heures (pour rester très gentil) à débugguer.

Edit: ha, ha, en voulant tester un peu ton code, je me suis rendu compte à quel point c'est tordu ton truc. En fait je supposais que la fonction memcpy() copiait les octets en commençant par les adresses basses. Ce qui fait que ton motif initial va se répéter sur le reste du tableau. Apparamment, ce n'est pas comme ça que ça fonctionne avec MinGW sous XP, qui se rapproche en fait plus de memmove. Bref, FUBAR.

Message cité 1 fois
Message édité par tpierron le 12-02-2008 à 21:16:51

Elmoricq

Modérateur

tpierron a écrit :

Edit: ha, ha, en voulant tester un peu ton code, je me suis rendu compte à quel point c'est tordu ton truc. En fait je supposais que la fonction memcpy() copiait les octets en commençant par les adresses basses. Ce qui fait que ton motif initial va se répéter sur le reste du tableau. Apparamment, ce n'est pas comme ça que ça fonctionne avec MinGW sous XP, qui se rapproche en fait plus de memmove. Bref, FUBAR.

Voila. [:romf]
Spour ça que je disais que je ne voyais rien d'anormal. [:klem3i1]

dave_tetehi

cat /dev/urandom > /dev/fb0

Le but, c'est de faire de la répétition de pattern.
Sauf erreur de ma part et quelque soit l'environnement, memcpy() et memmove() n'ont aucune raison de partager la même implémentation.
memcpy() progresse par ordre croissant d'addresse, alors que memmove (il me semble) procede par la fin d'abord (pour feinter le chevauchement).

Moi aussi, ca me semblerait être une pratique autorisée... Le truc, c'est que l'implémentation de memcpy fais de la copie, non pas a coup d'octet, mais le plus souvent a coup de double. Ca et des histoires d'alignements pourraient eventuellement poser des problemes pour les motifs de petites tailles. Il me semble egalement que c'est un comportement documenté, en tous cas, j'ai déjà lu ça a plusieurs reprises.
Bref, est-ce que c'est bien de faire ca ? Est-ce que j'ai la garantie d'obtenir toujours le bon résultat, et cela, peu importe l'implementation de la librairie standard (Visiblement non, puisque ca n'a pas l'air de marcher avec mingw). Peut etre en étant moins gourmant, et en se restreignant a toutes les versions de gcc (donc la glibc), a t-on cette garantie ?

ps: pourquoi faire une fonction dédiée, si c'est le comportement naturel de memcpy.

Merci pour toutes vos réponses.

Ace17

Mais t'as lu les reponses avant de reposter? Y'a au moins deux fois la reponse a ta question!
Et si memmove se comporte comme tu dis (en commencant par la fin) alors il y a aussi un probleme si les deux zones memoire se chevauchent.

matafan

Ton code est faux sur le principe, point. Rien ne garanti qu'il va marcher.

Taz

bisounours-codeur

memmove ça gère la superpostion mais que dans un sens.

Tarabiscote

Heureusement que ca gère les deux sens

memmove ensures that the original source bytes in the overlapping region are copied before being overwritten.

http://msdn2.microsoft.com/en-us/l [...] r43e1f34d2

Message édité par Tarabiscote le 13-02-2008 à 14:10:22

Publicité

Taz

bisounours-codeur

tu as raison, je me suis mal exprimé, j'ai un mauvais souvenir de rotation de données où memmove ne marchait pas

Emmanuel Delahaye

C is a sharp tool

dave_tetehi a écrit :

Code :

int t[100];
t[0] = 0, t[1] = 1, t[2] = 2, t[3] = 3;
memcpy(t+4, t, 96*sizeof(int));

Comportement indéterminé. Utiliser memmove() pour copier dans le même tableau..

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/

FORUM HardWare.fr

Programmation

Apropos de memcpy

Sujets relatifs
[C++] Utilisation de memcpy	[memcpy] L'importance de l'optimisation dans la copie des données
[swing] jai une qestion apropos de ActionEvent event	[C] tableaux à 2 dimensions et memcpy
[VC++?MFC] Concernant le "apropos de...." généré auto	[ASM] j'arrive pas à assembler memcpy optimisé pour amd:!
Plus de sujets relatifs à : Apropos de memcpy

Page générée en 0.087 secondes