Gast
#4351883
1 | |
2 | |
3 | |
4 | |
Warum werden, wenn 0xbffff7c0-0xbfffg7b0=16 ergibt, 32 Hexadezimalzahlen angezeigt. Es müssten doch 16bit d.h. 2byte angezeigt werden...
|
Anzeige
|
Gdb: Speicherbezeichnung unklar
Gast
#4351883
Warum werden, wenn 0xbffff7c0-0xbfffg7b0=16 ergibt, 32 Hexadezimalzahlen angezeigt. Es müssten doch 16bit d.h. 2byte angezeigt werden... Vielleicht solltest du mal die komplette Ausgabe hier reinkopieren ... Ich würde erwarten dass das 16*sizeof(passwort) Bytes ausgibt. Wenn das die komplette Ausgabe ist (warum dann die Punkte?) und sizeof(passwort) = 2, dann passt doch alles.
Gast
#4351930
Gast
#4351936
Es sind doch Hexa-Zahlen... Wenn 16*sizeof(passwort)=16*2byte!=16^32 Michael schrieb: > Warum werden, wenn 0xbffff7c0-0xbfffg7b0=16 ergibt, 32 Hexadezimalzahlen > angezeigt. Es müssten doch 16bit d.h. 2byte angezeigt werden... Nein. Das sind 16 Byte, nicht 16 Bit. Speicheradressen beziehen sich auf Bytes, nicht auf Bits. Und damit sind es --je nach gewählter Darstellung-- entweder 16 8-Bit-werte oder 8 16-Bit-Werte oder 4 32-Bit-Werte pro Zeile. Alles in Ordnung. Sven B. schrieb: > Ich würde erwarten dass das 16*sizeof(passwort) Bytes ausgibt. Nein, die Größe des entsprechend Objekts würde beim p[rint]-Kommando berücksichtigt. Das Memory-Dump-Kommando x interessiert sich nicht dafür, hier wird das entsprechende Symbol („passwort“) nur benutzt, um die Adresse zu ermitteln, ab der die Daten darzustellen sind. Ansonsten: Modifier ‘w’ sind hier halt „richtige Wörter“, also 32 Bit. Wer 16 Bit haben will, müsste im GDB den Modifier ‘h’ nehmen, also „Halbwörter“:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|