2013-05-29 7 views
0

J'ai pris l'argument de la fonction comme char *, dans mon cas, j'ai XOR égal à 210. De l'autre côté, dans l'autre VS j'ai pris le premier argument pas char * mais simplement char [] et le XOR est 114, ce qui est correct.char * et char [] n'obtiennent pas la même sortie

Qu'est-ce qui ne va pas? pourquoi je ne peux pas obtenir la même chose ici?

merci pour vos réponses.

MISE À JOUR: Vous avez raison. sprintf() fonctionne bien. Le problème est le reste du code.

bool BuildAnglePacket(char* WR_PacketAZAngle, float AZAngle) 
{ 

    WR_PacketAZAngle[0] = 0x04; 
    WR_PacketAZAngle[1] = 0x30; 
    WR_PacketAZAngle[2] = 0x31; 
    WR_PacketAZAngle[3] = 0x02; 
    WR_PacketAZAngle[4] = 0x79; 
    WR_PacketAZAngle[5] = 0x4E; 
    WR_PacketAZAngle[6] = 0x48; 

    int XOR; 
    char HAnlge[9]; 
    int iAzimuthAngle; 

// AZAngle = 22; 

    if (AZAngle >= -22.5 && AZAngle <= 22.5) 
    { 
     iAzimuthAngle = AZAngle*10; 

     if(AZAngle < 0) 
     { 
      iAzimuthAngle= abs(iAzimuthAngle); 
      iAzimuthAngle=((~iAzimuthAngle)&0xFFFF) + 1 ; 
     } 

     iAzimuthAngle = 65536 + iAzimuthAngle; 

     sprintf(HAnlge,"%08X", iAzimuthAngle); 

     WR_PacketAZAngle[7] = HAnlge[0]; 
     WR_PacketAZAngle[8] = HAnlge[1]; 
     WR_PacketAZAngle[9] = HAnlge[2]; 
     WR_PacketAZAngle[10] = HAnlge[3]; 
     WR_PacketAZAngle[11] = HAnlge[4]; 
     WR_PacketAZAngle[12] = HAnlge[5]; 
     WR_PacketAZAngle[13] = HAnlge[6]; 
     WR_PacketAZAngle[14] = HAnlge[7]; 
     WR_PacketAZAngle[15] = 0x03; 

     for(int i=4;i<16;i++) 
      XOR ^= WR_PacketAZAngle[i]; 

     WR_PacketAZAngle[16] = XOR; 
     WR_PacketAZAngle[17] ='\x0'; 
    } 

    return true; 
} 

Résolu: Oui, j'ai oublié d'initialiser XOR.

+0

Puisque vous ajoutez 65536 (0x10000) à votre petit nombre, comment le troisième chiffre hexadécimal pourrait-il être autre chose que 1? La sortie 'sprintf' de Linux semble correcte (sauf que vous n'affichez pas la valeur exacte de' iAzimuthAngle'). – user4815162342

+3

Comment appelez-vous sprintf avec un seul caractère au lieu de char * sans avoir une erreur de compilation? En outre, hex 96 est 150, pas 15. – riv

+0

Pouvez-vous poster un exemple complet, compilable, qui ne se comporte pas comme vous l'attendez, avec vos attentes? – user4815162342

Répondre

2
int iAngle = 15; // for example 
char HAngle; 

iAngle = 65536 + iAngle; 

Alors iAngle == == 65536 + 1565551 qui dans l'hexagone est 0x0001000F. Si vous avez imprimé cela à une chaîne, ne devriez-vous pas obtenir ce qui suit?

[0] 48 '0' 
[1] 48 '0' 
[2] 48 '0' 
[3] 49 '1' 
[4] 48 '0' 
[5] 48 '0' 
[6] 48 '0' 
[7] 70 'F' 
[8] 0 '\0' 

Certes, l'indice 3 doit toujours être un hexagone 1 dans ce cas?

Il ressemble à la fonction Windows fait quelque chose d'étrange ...

également HAngle devrait être un tableau si vous allez imprimer, sinon vous déborde ainsi le stockage qui lui est alloué. Vous semblez être capable de le traiter comme un pointeur lorsque vous appelez sprintf donc je suppose que vous voulez dire char *HAngle et avez alloué de la mémoire pour le tampon avant de l'imprimer?

EDIT: De votre code mis à jour il semble que XOR n'est pas initialisé? Si ce n'est pas le cas, il pourrait commencer avec n'importe quelle valeur aléatoire (le compilateur n'a pas besoin de le mettre à zéro, j'ai peur :)). Cela pourrait expliquer les différents résultats. Sur les deux côtés, il peut avoir une valeur initiale arbitraire et il arrive juste d'un côté à avoir une valeur initiale nulle ...

+0

oui j'ai attribué le paquet de caractères [18]; avant d'appeler la fonction ci-dessus. – Sam

+1

Ok. XOR n'est pas initialisé - cela pourrait être le problème – Jimbo

5

Votre problème n'est pas avec sprintf_s ou sprintf. Valeur 65536 + 150 => 65686 => 0x10096.

C'est le résultat correct tel qu'imprimé par votre code, tout le reste serait un bug. BTW, je pense que vous vouliez dire 150, pas 15, comme 0x96 => 150.

peut-il être que iAngle dans votre version de Windows est non signé court, donc il encapsule et vous obtenez réellement 150 au lieu de 65536 + 150? Cela expliquerait la sortie de '00000096' mais cela signifie que c'est un bogue dans le code de calcul original, pas avec l'impression elle-même.

BTW, je suppose que le vrai code n'a pas char HAngle; mais quelque chose comme char HAngle[..]; sinon tout peut arriver dans le cas où le compilateur s'endort pour une raison quelconque et ne produit pas une erreur.

EDIT: Le code mis à jour montre que XOR n'est pas initialisé et il peut contenir quoi que ce soit avant qu'il ne soit utilisé dans le calcul, vous pouvez obtenir un résultat. Vous devez d'abord le mettre à 0. Côté Windows, cela fonctionnait probablement si vous testiez la version de débogage qui définit les variables intégrales à 0 ou par pur hasard.

+0

oui j'ai alloué le paquet de caractères [18]; avant d'appeler la fonction ci-dessus. – Sam

+1

ok - puis vérifiez le type de 'iAngle' dans le code de Windows. Quel compilateur utilisez-vous? –

+0

iAngle est un nombre entier. le compilateur est visuel c – Sam

2

La question originale n'a pas beaucoup de sens: le code ne compilera pas à moins que vous ne changiez HAngle en un tableau (ou un pointeur vers un tableau); l'hex 96 est le nombre décimal 150, pas 15; et vous obtenez le 1 supplémentaire parce que vous ajoutez 65536 (hex 10000) à la valeur.

Dans la question mise à jour, vous obtenez une valeur indéterminée pour XOR (et un comportement techniquement indéfini) puisque vous ne l'initialisez jamais. Vous voulez:

int XOR = 0; 
     ^^^