recv: Unbekannte Anzahl Zeichen empfangen

proggingmania

CStoll schrieb:

Ich würde mal sagen, gleich am Anfang Wenn du realloc() einen NULL-Zeiger übergibst, liefert er dir nicht-initialisierten Speicher - und der ist insbesondere nicht null-terminiert.

Darum hat er wohl auch

if(loop_count == 0){
            user_string[0] = '\0';
        }

den hier mit reingesetzt.

proggingmania

Was sind denn das für Daten, die reinkommen ? Evtl. Binärdateien mit Nullbytes ?

Nein eigentlich ein ganz normaler String...

proggingmania

Mit deinem ZeroMemory - Parameter sieht das nicht gut aus ( NULL )
Aber ich glaub das ist es auch nicht, denn der Puffer wird sowieso immer von recv geleert nicht wahr.

CStoll

Und wie groß ist recieve_buffer? recv() nutzt den übergebenen Speicherplatz vollständig aus, also mußt du mindestens ein Byte mehr bereitstellen als du ihm zugestehst (für das abschließende '\0').

proggingmania

Wie gross ist receive_buffer
und wie gross ist SOCKET_RECEIVE_BUFFER ???

Könnte mir vorstellen, wenn SOCKET_RECEIVE_BUFFER einen zu grossen Wert hat, das dann etwas von den Daten flöten geht ?
Oder wie ? Hä ?

So, Problem gelöst, alles was zu tun war, war den receive_buffer und den user_string an den richtigen orten zu terminieren, sowie ein Zeichen weniger von recv zu lesen.
Anschliessend funktioniert das ganze wunderbar.
Vielen Dank für eure Hilfe auf jeden Fall

proggingmania

rüdiger

btw. würde ich nicht für jedes recv ein realloc aufrufen, weil realloc nun mal sche*ße lahm und potentiell fehleranfällig ist. An deiner Stelle würde ich immer größere Speicher-Blöcke allozieren (2er Potenzen) und dann schauen ob genug Speicher noch übrig ist nach jedem recv und erst dann realloc benutzen (um den nächst größeren Block (2er Potenz) zu allozieren).

Wenn du die Größe des Buffers kennst, dann kannst du auch gleich memcpy nehmen und nicht strcpy

Javaner

rüdiger schrieb:

weil realloc ... potentiell fehleranfällig ist.

Wieso das denn?

@rüdiger: Würdest du bitte mal antworten?