0
Ich bemerke ein merkwürdiges Verhalten mit scanf im NASM Assembly Code. Ich habe zwei Anrufe scanf:x86 NASM ändert Wert bei Adresse, die nicht als Parameter übergeben wurde
mov rdi, fmt
mov rsi, r14
call _scanf
und
mov rdi, fmt
mov rsi, r15
call _scanf
wo fmt im data Abschnitt deklariert als:
section .data
fmt: db "%d", 0
Vor dem ersten scanf, die Adressen in R14 und R15 sind:
r14 = 0x0000000000002104
r15 = 0x0000000000002105
In LLDB, me read -fd -c1 auf eine dieser beiden Adressen Ausgänge ist zum Glück 0.
Nach der Eingabe von "2" zum ersten scanf, wird der Wert in 0x0000000000002104 Ausführung 2.
After "2" für die zweite Eingabe scanf ist der Wert in 0x0000000000002105 2. doch nun der Wert in 0x0000000000002104 ist 514.
ich nach Anruf zu scanf an anderen Orten ähnliche Änderungen im Speicher erlebe und werde sie reproduzieren, wenn nötig, aber wollte wissen, ob jemand habe das erlebt.
Die Adressen 2104 und 2105 sind ein Byte voneinander entfernt, aber Sie verwenden "% d", das eine 4 Byte große Ganzzahl füllt und die Bytes nach dem Ort, an dem Sie versuchen, zu überlesen. Ihnen fehlt ein minimales vollständiges überprüfbares Beispiel. Sie sollten Ihren Code einfach posten und wir können ihn besser verstehen. Ist das auf MacOS? und hast du das _AL_ register vor dem scanf auf null gesetzt? –
514 ist 0x0202, dh die DWORD-Kombination der Bytewerte in 2105 und 2104. – prl
@MichaelPetch: Sie können '[mcve]' in Kommentaren verwenden: es wird zu [mcve] erweitert. Das ist fast zu wenig, aber ich denke, dass diese spezifische Frage darauf basiert. Ich denke, dass Sie überprüfen möchten, welche Breite das OP verwendet, um die ganzzahligen Werte nach scanf zu lesen, um sicherzustellen, dass es ein dword ist, passend zu der Breite von "int", die "% d" speichert? –