recv: Unbekannte Anzahl Zeichen empfangen

Was ist user_string_length für ein datentyp, vielleicht wirds ja negativ.
Oder aber, realloc liefert auch NULL, wenn nicht genung Speicher da ist

user_string_length ist ein int. Jedoch empfange ich nicht soviele Daten, als das er negativ werden könnte.

realloc funktioniert perfekt, solange ich keine Daten in die Strings schreibe, sprich, ich kann alle daten empfangen jedoch fehlt mir noch der richtige weg sie abzuspeichern. Irgendwo scheint noch ein Fehler im Code zu sein, jedoch habe ich noch keine Ahnung wo.

CStoll

Hast du denn konsequent die Null-Terminierung der beteiligten Strings beachtet? (zumindest im ersten Schleifendurchlauf liefert realloc() nichts nullterminiertes) Wenn nein, bist du vermutlich munter dabei, die Kontrollstrukturen des Heaps zu pulverisieren.

CStoll schrieb:

Hast du denn konsequent die Null-Terminierung der beteiligten Strings beachtet? (zumindest im ersten Schleifendurchlauf liefert realloc() nichts nullterminiertes) Wenn nein, bist du vermutlich munter dabei, die Kontrollstrukturen des Heaps zu pulverisieren.

Ja genau das meint mein Debugger auch.
Folgendes ist mein Code:

do  {
		ZeroMemory(receive_buffer, NULL);
		nret=recv(theSocket, receive_buffer, SOCKET_RECEIVE_BUFFER, 0);
		user_string_length = user_string_length + nret;
		user_string = (char*) realloc(user_string, user_string_length + 1);

		if(user_string == NULL){
			MessageBox(NULL, "Could not allocate enough memory", "Title", MB_OK);
			return NULL;
		}

		if(loop_count == 0){
			user_string[0] = '\0';
		}
		strcat(user_string, receive_buffer);
		user_string[user_string_length] = '\0';
		loop_count ++ ;
	} while (nret > 0);

Ich kann beim besten willen nicht sagen wo ich da eine Nullterminierung vergessen habe. Aber ich bin sicher der Fehler ist was kleines und total klar...

CStoll

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.

Ok...

tut mir leid verstehe ich nicht ganz

Ich kriege ja Speicher zurück oder etwa nicht?

Diesen terminiere ich doch dann hier:

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

Oder was zum Henker ist denn das?

Oh man ich muss noch viiiiel lernen; )

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?