memcmp (längenparam)

natürlich können sie nicht gleich sein, wenn die speicherbereiche nicht gleich sind...

es können eben beide möglichkeiten vorkommen - ansonsten würde ja memcmp auch funktionieren. Werd dann strcmp verwenden.

vielen dank
Udo

LordJaxom schrieb:

Es ist aber nicht bestimmt, welcher "größer" ist.

grösser ist der, dessen erstes zeichem grösser ist, als das zeichen an der selben position im anderen array.

Udo_schonbesetzt schrieb:

Werd dann strcmp verwenden.

geht aber nur, wenn beide arrays eine 0 am ende haben.

ok eine null haben sie am ende nicht, da es sich um byte-folgen handelt (hexazahlen).

udo

LordJaxom

cmp-freak schrieb:

grösser ist der, dessen erstes zeichem grösser ist, als das zeichen an der selben position im anderen array.

Und genau das kann man (auch) mit memcmp herausfinden, auch wenn die Anzahl der Zeichen unterschiedlich ist. Um nichts anderes ging es mir

udo_schonbesetzt schrieb:

ok eine null haben sie am ende nicht, da es sich um byte-folgen handelt...

dann kannste strcmp() schon mal knicken.
vergleich doch zuerst die längen. sind die gleich dann mach noch ein 'memcmp' hinterher.

Udo_schonbesetzt schrieb:

hi,

wenn man zwei char ptr miteinander vergleichen möchte (mittels memcmp), aber es vorkommen kann, dass nicht beide die gleiche Länge besitzen - muss man dann jeweils die kürzere Länge des einen char ptrs als dritten Parameter von memcmp verwenden?

Ansonsten könnte es doch passieren, dass man auf fremden Speicherbereich (einer anderen Fkt etc.) zugreift.

Gruß
Udo

ja

pointercrash**

Udo_schonbesetzt schrieb:

- muss man dann jeweils die kürzere Länge des einen char ptrs als dritten Parameter von memcmp verwenden?

[Function]Compares memory areas ('n' bytes).

[Format]#include <string.h>
int memcmp( s1, s2, n );

[Method]function

[Argument]
const void *s1; Pointer to the first memory area to be compared 
const void *s2; Pointer to the second memory area to be compared 
size_t n; ........... Number of bytes to be compared

[ReturnValue]
 Return Value==0 The two memory areas are equal.
 Return Value>0 The first memory area (s1) is greater than the other.
 Return Value<0 The second memory area (s2) is greater than the other.

[Description]

 Compares each of n bytes of two memory areas

In dem Sinne "ja". Das mit den Strings ist in C über den unglückseligen "0"- Terminator geregelt, deswegen tatsächlich Finger weg von Stringfunktionen, wenn Du nur Bytesequenzen vergleichen magst.

Ich frag' mich zudem, wofür das memcmp gut sein mag, es scheint mir besonders nutzlos, aber was soll's

man kann damit ganze speicherblöcke auf einmal vergleichen, ist doch toll.

pointercrash() schrieb:

Ich frag' mich zudem, wofür das memcmp gut sein mag, es scheint mir besonders nutzlos, aber was soll's

dieses 'grösser' oder 'kleiner' fand ich auch immer seltsam, bis ich mal mit kryptografie-code (802.11i) rumgefrickelt habe, der das tatsächlich brauchte.

d.h. zusammengefasst:

zuerst die kleinere Länge der Byte-Daten herausfinden und dann memcpy anwenden (als dritter Parameter die kleinere Länge)...

memcpy ist sehr hilfreich im Bereich Netzwerktechnik (Ethernet-Dataframes z.B.)

gruß
Udo

Kann auch ganz geschickt sein wenn man Strukuren auf Gleichheit überprüfen will. Da muss man beim Erstellen natürlich auf das Padding aufpassen.

Tim schrieb:

Kann auch ganz geschickt sein wenn man Strukuren auf Gleichheit überprüfen will. Da muss man beim Erstellen natürlich auf das Padding aufpassen.

https://www.securecoding.cert.org/confluence/display/seccode/EXP04-A.+Do+not+perform+byte-by-byte+comparisons+between+structures

Oh, ich hätte vielleicht noch erwähnen sollen, dass man beim Erstellen auf das Padding aufpassen muss

pointercrash**

Also das mit der Überprüfung auf Gleichheit mag ja ganz lustig sein, aber die Funktionalität läßt sich doch in einem Fünfzeiler unterbringen.

Seltsam kommt mir halt die größer/kleiner- Aussage vor, da sie sich nur der konsekutiven Bytefolgen annimmt und logischerweise nichts über den typisierten Inhalt sagen kann.
Mich hat eigentlich dann immer die Stelle interessiert, an der sich die Blöcke unterscheiden (Telegrammauswertung) und genau das liefert memcmp nicht.

Geht's euch nicht auch öfters so, daß man sich zuerst freut, weil was fertig in der Lib ist und man dann feststellen muß, daß man's so gar nicht brauchen kann?
Also dann doch wieder "Handgeschnitztes"

Mr.Rolleyes schrieb:

Oh, ich hätte vielleicht noch erwähnen sollen, dass man beim Erstellen auf das Padding aufpassen muss

hast du. betrachte den link als ergänzung. memcmp auf c-structs angewandt ist trotzdem übel und sollte man lieber lassen.

pointercrash() schrieb:

Also das mit der Überprüfung auf Gleichheit mag ja ganz lustig sein, aber die Funktionalität läßt sich doch in einem Fünfzeiler unterbringen.

library-funktionen wie memcmp etc. sind oft auf speed ausgelegte asm-codes. selbermachen wird meist langsamer sein.

pointercrash**

struct-freak schrieb:

library-funktionen wie memcmp etc. sind oft auf speed ausgelegte asm-codes. selbermachen wird meist langsamer sein.

Richtig, aber wenn ich das nicht rauskriege, was ich brauche, hilft keine Speed der Welt :p .
In dem Fall wurde ein Token- Frame rumgeschubst und die Adresse des Streamers ergibt sich aus der Position im Buffer, die ich deswegen brauche. memcmp ist tatsächlich 20% schneller als mein Gebastel, aber nochmal - es hilft ja nix.

pointercrash() schrieb:

...
Seltsam kommt mir halt die größer/kleiner- Aussage vor, da sie sich nur der konsekutiven Bytefolgen annimmt und logischerweise nichts über den typisierten Inhalt sagen kann.
Mich hat eigentlich dann immer die Stelle interessiert, an der sich die Blöcke unterscheiden (Telegrammauswertung) und genau das liefert memcmp nicht.

pointercrash, in mir kommt der Verdacht auf, dass Du nicht verstehst, wie
memcmp() (d.h. byteweises Vergleichen von Speicherbereichen!) arbeitet.
Padding-Wirrwar beim Verwenden einer konkreten Struktur, kann es nicht geben!
Stellen an denen sich Speicherinhalt unterscheidet, werden von memcmp() immer gefunden.

MfG

pointercrash**

willy schrieb:

pointercrash, in mir kommt der Verdacht auf, dass Du nicht verstehst, wie memcmp() (d.h. byteweises Vergleichen von Speicherbereichen!) arbeitet.

Und in mir kommt der Verdacht auf, daß Dir nicht klar ist, daß byteweises Vergleichen auf größer/kleiner bis zur totalen Sinnlosigkeit kontextbefreit ist.

willy schrieb:

Padding-Wirrwar beim Verwenden einer konkreten Struktur, kann es nicht geben!

Wenn das Moses sagt, wird er sein Volk nach Kanaan führen müssen. Ich hatte durch die Postings vorher ein paar lehrreiche Aha- Erlebnisse.

willy schrieb:

Stellen an denen sich Speicherinhalt unterscheidet, werden von memcmp() immer gefunden.

Bestreite ich nicht, aber es nützt mir so wenig wie der Beweis, daß ich ein zehn Zentimeter großes Loch durch meine Klotür bohren kann. Ich brauch's einfach nicht und memcmp genauso wenig.

pointercrash() schrieb:

Und in mir kommt der Verdacht auf, daß Dir nicht klar ist, daß byteweises Vergleichen auf größer/kleiner bis zur totalen Sinnlosigkeit kontextbefreit ist.

nimm mal mal zwei zahlen, 123456 und 123476. wenn du die ziffern von links nach rechts vergleichst, wirste bei der 5ten stelle (von links) einen unterschied feststellen. der grössenunterschied einer einzelnen ziffer entscheidet, ob die gesamte zahl grösser oder kleiner ist. egal wie die ziffern rechts davon aussehen. das selbe gilt auch manchmal für bytefolgen.

pointercrash**

stellenwertsystem-freak schrieb:

nimm mal mal zwei zahlen, ... , ob die gesamte zahl grösser oder kleiner ist. ... das selbe gilt auch manchmal für bytefolgen.

Manchmal ... eben
Little oder big endian? Damit fängt's an und es wird sich weiter ergeben, daß sich für solche Sachen kontextbezogenes Parsing empfielt, memcmp() spart mir da gar nichts.