... wenn die Leute so verschissenen Code schreiben, brauchen sie sich auch nicht wundern wenn jeden Tag zig neue Sicherheitslöcher gefunden werden.
[...]
void SkilllistCmd(unsigned char *data, int len)
{
char *tmp, *tmp2, *tmp3, *tmp4;
[...]
strncpy(name, data , (uint32)tmp2-(uint32)data );
[...]
Von der "kreativen" Indentation mal abgesehen - HACKTS? Ratet mal was passiert, wenn man versucht, Daimonin auf x86-64 zu spielen. Richtig, es SEGVed noch im Ladebildschirm!
Dass der Code überhaupt irgendwo funktioniert ist schon ein Wunder an sich. Die Verwendung von unsigned char * und char * wechselt im Code frei Schnauze. Und wenn die beiden aufeinandertreffen, castet man halt schnell auf uint32. Nein, nicht uint32_t, wie man es in jeder anständigen stdint.h findet, uint32 muss es sein. Schon mal was von ptrdiff_t gehört? Nein? Liegt vielleicht daran, dass stdlib.h gleich gar nicht eingebunden wird! Und malloc, free, strtoul etc. legt der Weihnachtsmann unter den Baum.
Es wird gemeinhin behauptet, es wäre nicht möglich, 100% sicheren Code zu schreiben. Das ist Schwachsinn, Microsoft deluxe. Es ist vielleicht nicht einfach, aber wer's nicht kann soll bitte nicht C nehmen.
Nachtrag: Anscheinend liefert der Server sowieso gerade nur Null-Bytes statt Charakterdaten, was den Client mangels Fehlerbehandlung in die nächste SEGV schickt.
Ist nicht gesagt
2005年10月08日 (土曜日) 20時17分Der Cast ist natürlich völlig überflüssig, weil die Differenz zweier Pointer ein Integer-Datentyp ist, und da wir hier char* abziehen, ist das auch in Bytes.
Aber das Ergebnis ist auch auf x86_64 korrekt, außer die Differenz wäre größer als 32 Bit.
Mist
2006年01月04日 (水曜日) 02時31分Hast recht. Ich hatte das in einem Rutsch mit "wir quetschen Pointer in int" gefixed, und danach ging's halbwegs, was mich wohl zu der falschen Folgerung verleitet hat es hätte hieran gelegen.
nichtso ganz richtig...
2005年12月31日 (土曜日) 16時37分In C sind alle Pointer immer vom gleichen arithmetischen Typ. Man kann auch einen Pointer zu einer union oder struct arithmetisch von einem Pointer zu char* abziehen. oder einem &int.
Die cast sind schon unsinnig - aber Daimonin ist ein cross-system Projekt und die casts ergaben sich durch lustige side effects mit einem compiler auf einer sun. der compiler oder strcpy() der dortigen standard libs mochte die impliziten casts nicht, also musste man hard-casten. Der client ist im cvs schon seid längeren nun auf x86-64 umgestellt und der server auch und die casts sind weg. Sowas gehört dazu wenn man real Software auf unterschiedlichen Systemen entwickelt. Soviele Projekte, die auf dem Level cross-plattform laufen wie underes, gibt es nicht.
Ansonsten hast du den code nicht wirklich verstanden.
Warum "unsigned char *data"? Das ist ein binärer, abstrakter input stream. Darum ist er vom neutralen typ "unsigned char *" = byte. Er kann alles sein. Kodierte int64, text, music... Unser Server kann ja auf xyz vector Rechner laufen, wo er in nibbles rechnet, oder was auch immer. Also codiert der Server seine Daten immer in neutrale bytes.
Da SkilllistCmd() weiss, das diese Bytes nun Text für ihn sind, transformiert er sie um. Was du als sinnlose casts von unsigned to signed char gesehen hast, ist die logische Datentransformation, die ja irgendwann dann auch physikalisch werden muss.
Ansonsten: Daimonin ist open source. Wenn du unseren Code verbessern kannst - machs. Nur so wird open source gut und besser. Du bist jederzeit willkommen.
Ja, ok...
2006年01月04日 (水曜日) 02時26分Erst mal Entschuldigung - als ich den Eintrag geschrieben hab' war ich stinksauer und frustriert. Dass x86_64 im CVS supported war, hat mich dann erst recht sauer gemacht weil ich umsonst stundenlang an dem Code rumprobiert hatte... bitte nicht böse sein. *duck*
Dass Pointer in C immer vom gleichen arithmetischen Typ sind ist allerdings schlichtweg falsch, wie man an einem Beispiel sieht:
#include <stdio.h> int main() { int i[2]; char c[2]; printf("int: %d, char: %d\n", &i[1] - &i[0], &c[1] - &c[0]); return 0; }Ausgabe: int: 1, char: 1
Dass Portabilität solche Hacks manchmal erfordert, ist mir klar. Trotzdem ist der Code *verdammt* unübersichtlich. Und auch Hacks kann man richtig und falsch machen. Richtig wäre in dem konkreten Beispiel ein Cast auf "char *" gewesen.
Verstanden habe ich den Code wirklich nicht, und genau das ist das Problem. Logischerweise kann ich auch nicht verbessern, was ich nicht verstehe...