Archiv verlassen und diese Seite im Standarddesign anzeigen : [ANSI-C] Zwei "Strings" vergleichen
Hallo !
Ich hab ein kleines Problem:
unsigned char buffer1[Länge wird über Programm festgelegt];
unsigned char buffer2[Länge wird über Programm festgelegt];
In diesen beiden Puffern stehen in der Regel 7 Byte als HEX-Werte drin, also z.B.
B3 4C 11 00 3B 40 00 oder auch noch anders ausgedrückt:
In buffer[0] steht B3
in buffer[1] steht 4C
usw.
Eingelesen wird das über eine kleine Routine recByte.
Wie kann ich jetzt die Puffer auf Gleichheit der Inhalte prüfen ? strcmp usw. haut ja so nicht mehr hin.
Zur Info: Es muss reines ANSI-C sein, nix mit Windows und so ;)
Danke euch !
UliBär
2007-10-04, 14:16:02
memcmp ?
http://www.cplusplus.com/reference/clibrary/cstring/memcmp.html
Wird hier nicht auch nur wieder die Anzahl der characters verglichen ?
Ich meinte das eher so:
In buffer1 steht meinetwegen B3 4C 11 00 3B 40 00
in buffer2 steht B3 4C 11 00 3B 41 20
Die letzten beiden Bytes unterscheiden sich also und das soll erkannt werden.
Nein. memcmp ist was du suchst.
UliBär
2007-10-04, 14:23:47
Hast Du meinen Link überhaupt gelesen?
Return Value
Returns an integral value indicating the relationship between the content of the memory blocks:
A zero value indicates that the contents of both memory blocks are equal.
A value greater than zero indicates that the first byte that does not match in both memory blocks has a greater value in ptr1 than in ptr2 as if evaluated as unsigned char values; And a value less than zero indicates the opposite.
Ah sorry, ich hab in der Visual Studio Hilfe nur schnell memcmp eingegeben und da wurde das etwas mißverständlich erklärt. In deinen Link hab ich nicht reingeschaut *schäm* :D
Also ich hab es jetzt so gemacht wie in dem Link, folgendes passiert:
in buffer1 steht: B3 4C 11 00 3B 40 00
in buffer2 steht: B3 4C 11 00 3B 40 00
Wenn ich die beiden vergleiche isses OK ! -> equal
Wenn ich das erste oder das zweite Byte ändere, wird richtigerweise "not equal" erkannt.
Ab dem 3. Byte sagt er allerdings nur noch "equal", obwohl
in buffer1 steht: B3 4C 11 00 3B 40 00
in buffer2 steht: B3 4C C1 00 3B 40 00
alles andere als equal is :)
Dann hast du nen anderen Fehler.
UliBär
2007-10-04, 15:05:20
Parameters
ptr1
Pointer to block of memory.
ptr2
Pointer to block of memory.
num
Number of bytes to compare. ? :ugly:
Also wenn ich die Anzahl an Bytes direkt angebe (nämlich 7), dann klappt es !
Also:
result = memcmp(framebuffer, comparebuffer, 7);
if(result == 0) {
fprintf(stdout, "Buffers are equal\n");
} else {
fprintf(stderr, "Error: Buffers are not equal\n");
}
Da die Anzahl der Bytes aber variieren kann, ist das natürlich keine Lösung.
Mutter bei die Fische
2007-10-04, 15:12:03
Welcher Code produziert denn das nicht gewollte Verhalten? :)
size_t len1, len2;
int n;
len1=strlen(buffer1);
len2=strlen(buffer2);
n=memcmp(buffer1, buffer2, len1>len2?len1:len2 );
Dieser hier mit der entsprechenden if-Abfrage zum Ergebnis (n) :)
Achja, bitte nicht haun, ich bin so ziemlich absoluter Anfänger !
Also wenn ich die Anzahl an Bytes direkt angebe (nämlich 7), dann klappt es !
Dann gib halt die Anzahl an Bytes an die du alloziert hast. Willst du uns verarschen oder was?
len1=strlen(buffer1);
len2=strlen(buffer2); Dann setze in Deinem Visual Studio mal einen Breakpoint und schau Dir an was passiert...
hint: Du solltest eigentlich die Länge bereits wissen anstatt mit einer falschen Funktion dort nach der Länge zu suchen.
Nein, verarschen will ich hier niemanden !
Der Code des restlichen Programms stammt nicht komplett von mir und explizit alloziert wird hier nicht. Die Werte werden über stdin (also z.b in der Konsole programm.exe < testfile.txt) Zeichen für Zeichen durch eine Routine eingelesen und so auch in den buffer geschrieben. Das Textfile schaut etwa so aus:
> B3 4C 11 00 3B 40 00
< B3 4C 11 00 3B 40 00
Je nachdem, ob nun ein "<" oder ein ">" kommt, wird entweder in buffer1 oder buffer2 geschrieben. Die Routine übernimmt wie gesagt das Einlesen und beachtet natürlich auch Fälle wie "Leerzeichen", "\n" usw.
Wie gesagt, ich habe selber nicht soviel Ahnung von der Materie und man möge mir doch etwaiges für euch unverständliches Unwissen entschuldigen...
Grestorn
2007-10-04, 15:45:13
Nein, verarschen will ich hier niemanden !
Der Code des restlichen Programms stammt nicht komplett von mir und explizit alloziert wird hier nicht. Die Werte werden über stdin (also z.b in der Konsole programm.exe < testfile.txt) Zeichen für Zeichen durch eine Routine eingelesen und so auch in den buffer geschrieben. Das Textfile schaut etwa so aus:
> B3 4C 11 00 3B 40 00
< B3 4C 11 00 3B 40 00
Je nachdem, ob nun ein "<" oder ein ">" kommt, wird entweder in buffer1 oder buffer2 geschrieben. Die Routine übernimmt wie gesagt das Einlesen und beachtet natürlich auch Fälle wie "Leerzeichen", "\n" usw.
Wie gesagt, ich habe selber nicht soviel Ahnung von der Materie und man möge mir doch etwaiges für euch unverständliches Unwissen entschuldigen...
Du musst doch wissen, wieviele Bytes Du gelesen hast. Wenn nicht, lass nen Zähler mitlaufen.
Ok, mein Startpost sorgt wohl für das Unheil, da ich schlichtweg Bullshit geschrieben hab :D
Die Größe der Puffer ist mit [254] vorgegeben, das Maximum wird aber im Normalfall nie erreicht ! Die Routine prüft die Textfile auf "gültige" Zeichen und liest diese dann ein. Kommt im Textfile z.B. ein Zeilenumbruch "\n", so wird das Einlesen beendet und der Puffer ist "komplett".
Das mit dem Zähler wär mal ne Idee.
Grestorn
2007-10-04, 15:49:22
Ok, mein Startpost sorgt wohl für das Unheil, da ich schlichtweg Bullshit geschrieben hab :D
Die Größe der Puffer ist mit [254] vorgegeben, das Maximum wird aber im Normalfall nie erreicht ! Die Routine prüft die Textfile auf "gültige" Zeichen und liest diese dann ein. Kommt im Textfile z.B. ein Zeilenumbruch "\n", so wird das Einlesen beendet und der Puffer ist "komplett".
Es wundert mich zwar, dass '\n' als Endezeichen gilt, aber dennoch '\0' im String vorkommen kann... aber gut.
Du musst in der Leseschleife trotzdem zählen, wieviel Zeichen Du gelesen hast.
Oder alternativ (weniger effizient): Den Puffer vorher mit memset initialisieren und dann kannst Du den memcmp immer auf alle 254 Zeichen vergleichen lassen.
Ich kann dir grad mit deiner ersten Aussage nicht folgen (\n und \0), erklärst du mir das nochmal genauer ? :)
UliBär
2007-10-04, 16:05:15
strlen() bricht beim ersten 0-Byte ab!
strlen() bricht beim ersten 0-Byte ab!
Achso. Naja, strlen gibt's ja jetzt nicht mehr :)
Natürlich gibt's strlen noch.
Ich meinte in meinem Programm !
Mensch bist du aber beißwütig heute :D
HellHorse
2007-10-04, 19:14:53
Die Größe der Puffer ist mit [254] vorgegeben, das Maximum wird aber im Normalfall nie erreicht !
Du weisst wie Buffer Overflows entstehen?
Ja da kann ich auch nichts machen, es ist nunmal per Spezifikation vorgegeben, dass ein Frame aus maximal 254 Bytes (bzw. 256 Byte mit CRC aber das mach ich jetzt noch nicht) bestehen kann. Um euch nicht ganz im Dunkeln tappen zu lassen, das Thema is RFID und ich darf mich im Rahmen eines Praktikums um Antikollision und das Übertragungsprotokol kümmern.
Das Ganze is momentan noch ziemlicher Overkill für mich aber wenn, dann möchte man doch gleich richtig einsteigen :)
Grestorn
2007-10-04, 20:26:24
Ja da kann ich auch nichts machen, es ist nunmal per Spezifikation vorgegeben, dass ein Frame aus maximal 254 Bytes (bzw. 256 Byte mit CRC aber das mach ich jetzt noch nicht) bestehen kann. Um euch nicht ganz im Dunkeln tappen zu lassen, das Thema is RFID und ich darf mich im Rahmen eines Praktikums um Antikollision und das Übertragungsprotokol kümmern.
Das Ganze is momentan noch ziemlicher Overkill für mich aber wenn, dann möchte man doch gleich richtig einsteigen :)
Nur rein prinzipiell: Es ist ganz egal, was spezifiziert ist: Du musst Dich trotzdem dagegen absichern, dass mehr als 254 Bytes kommen. Sonst hast Du gleich eine der vielen Sicherheitslücken programmiert.
Leute, die auf ein System eindringen wollen, scheren sich einen Scheiß um Spezifikationen, im Gegenteil, sie freuen sich über jede Gelegenheit, die Spezi zu brechen.
Ein Zähler, der auf max. 254 Bytes prüft, würde schon reichen. Oder eine dynamische Pufferstruktur.
Ok, danke für deinen Rat :)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.