2013-04-12 4 views
-1

Je vais avoir quelques problèmes en utilisant memcpy en ce que lorsque l'opération est effectuée memcpy je reçois:memcpy caractères de départ supplémentaires

« ÍÍWF03-021913.datýýýý« «« «« «« «e »

quand je devrais obtenir:

« WF03-021913.datýýýý« «« «« «« «e »

Je ne sais pas où ces principaux « IĮ » viennent.

code:

Note: lpszFileName = "WF03-021913.dat"

typedef struct { 
    BYTE cbRequestType; 
    BYTE cbFileName; 
    char* szFileName;  
} UFTP_GET_FILE_INFO_REQUEST; 

BOOL Uftp_BuildFileInfoRequest(PUFTP_REQUEST request, LPCTSTR lpszFileName) 
{ 
    UFTP_GET_FILE_INFO_REQUEST *fileInfo; 
    int fileNameLen; 

    if (lpszFileName == NULL) { 
     ASSERT(0); 
     return FALSE; 
    } 

    fileNameLen = strlen(lpszFileName); 
    if (fileNameLen == 0) 
     return FALSE; 

    request->dwRequestSize = sizeof(UFTP_GET_FILE_INFO_REQUEST) - 
          sizeof(void*) + fileNameLen; 
    request->RequestBuffer = malloc(request->dwRequestSize); 
    if (!request->RequestBuffer) { 
     TRACE0("Failed to allocate RequestBuffer"); 
     return FALSE; 
    } 

    fileInfo = (UFTP_GET_FILE_INFO_REQUEST*) request->RequestBuffer; 
    fileInfo->cbRequestType = UFTP_GET_FILE_INFO; 
    fileInfo->cbFileName = fileNameLen; 

    memcpy(&fileInfo->szFileName, lpszFileName, fileNameLen); 
    return TRUE; 
} 
+0

Avez-vous essayé 'memcpy (& (nomFichier-> szFichierFichier), lpszFichierNom, nomFichierLen):' Je ne suis pas sûr de l'ordre de l'opérateur. – rekire

+2

Pouvez-vous nous montrer 'UFTP_GET_FILE_INFO_REQUEST'? – NPE

+0

Pourquoi utilisez-vous 'memcpy' au lieu de' strcpy'? –

Répondre

1

Je ne devine ici, mais je pense que fileInfo->szFileName est un pointeur . Cela signifie que &fileInfo->szFileName est un pointeur vers un pointeur, de sorte que vous copiez dans une autre zone complète de la mémoire.

De même, vous ne copiez pas le caractère de fin requis. Vous avez besoin de fileNameLen + 1 pour cela, à la fois lors de l'allocation et lors de la copie. Si vous voulez vraiment tout dans la mémoire contiguë, vous devriez probablement changer la structure pour finir avec un tableau de caractères de taille zéro (peut ne pas être supporté par votre compilateur, puis utiliser un tableau de taille 1) et utiliser sizeof(UFTP_GET_FILE_INFO_REQUEST) + fileNameLen + 1 comme la taille à allouer. Vous pouvez ensuite utiliser le tableau comme un tableau de chaînes normal.


Et si vous fixez ces problèmes, vous avez encore une autre problème: Vous n'initialisez pas le pointeur pour pointer vers la mémoire allouée. Cela signifie qu'il pointera vers une mémoire aléatoire.

Toutes ces erreurs conduiront à undefined comportement, et je dirais que vous êtes chanceux qu'il ne s'est pas écrasé.

+1

Le membre cbFileName possède la longueur, donc la valeur de terminaison n'est probablement pas requise. S'il copiait fileNameLen + 1, il dépasserait la quantité de mémoire allouée. (voir l'appel de malloc).Je suis d'accord avec le reste de cette réponse, sauf si szFileName est un membre flexible du tableau (que nous ne connaissons pas sans le voir). – WhozCraig

+0

@WhozCraig A moins que l'OP ne veuille vraiment les caractères étranges après ce qui ressemble à un nom de fichier correct, je pense qu'il l'utilise comme une chaîne normale à zéro terminé. –

+1

Cela pourrait bien être ce qu'il représente, mais si cela était requis dans le cadre de la structure, il n'y aurait pas besoin du membre cbFileName. Si * est * censé être une chaîne à terminaison nulle Vous pouvez ajouter un malloc sous-dimensionné à votre litanie de choses erronées. Et à en juger par la structure présentée dans le code mis à jour, il tente désespérément d'être une structure de membre de groupe flexible, mais échoue lamentablement. – WhozCraig

Questions connexes