recv в переменую!

считывай по байтово в цикле.

> а точный размер я могу получить только в recv,

т.е. тебе придет размер пакета ? Если да, то выделишь когда он придет, если нет, то первым байтом можно слать размер пакета, вообще эта тема поднималась уже не раз.

Читать по кускам, постепенно выделяя память.

>Но что делать если я не знаю сколько памяти мне нужно выделить в MAXDATASIZE

1)выделять с запасом

2)выделять по частям по мере вычитки

Поиск мне не дал ответ, количество присланных байт мне не известно.

Я вот так извратил не пашит.

#define STEP 1045 char buf[STEP];

char to[STEP]=""; while((numbytes = recv(sock, buf,sizeof(buf),0)) > 0) { if (numbytes == -1) {perror("numbytes"); exit(4);} if (strlen(to) == 0) strcpy(to,buf); else { realloc(to,strlen(to)+STEP); strcat(to,buf); } }

ерунда какая-то
первое, что бросается в глаза
char to[STEP]  объявлен в стеке
но ты его пытаешься ресайзить используя функции работы с динамической памятью.

а пойдика почитай букварь. может поможет.

Пример как раз из эл. книжеки. Я представляю что в букваре :)

char *to; Тоже не пашет.

вообще-то вы можете узнать, сколько данных есть
в сокете - ioctl(FIONREAD). но это плохой подход.

про выделять с запасом или читать кусками вам уже
сказали, это намного правильнее.

>Я представляю что в букваре :)

сомневаюсь. ты ведь его не читал.

>char *to; Тоже не пашет.

и не должен

glibc

Ну и какая страница.

>Ну и какая страница.

http://www.linuxdoc.ru/manpages/man3/malloc.3.html

Надо работать со строками? fscanf или что-то родственное поможет? Тогда просто "переоткрой" сокет с помощью fdopen и используй стандартные функции из stdio.. Это чтобы не морочить никому голову.

PS. Это не по теме, просто стало интересно, производительность от таких манипуляций пострадает? И как лучше всего настроить буфер для сокета (с помощью setvbuf например) для улучшения произодительности (обмен только текстом)?

Не то что бы плохой, просто не идеальный. Вот с его помощью хоть примерно и можно выделять с запасом. А то откуда знать какой запас? А тут хоть какой ориентир, больше чем FIONREAD данных в сокете не будет.

> больше чем FIONREAD данных в сокете не будет.

почему же? сразу после возврата из ioctl() могут
появиться новые данные. это и по другим причинам
неуклюжее решение.

Может быть использовать список, что-то вроде

#define BUF_SIZE 128
struct Node {
data char[BUF_SIZE];
int data_size;
Node *next;
}

И при чтении, если заполняется текущий узел - выделять новый. Большого перерасхода памяти не будет, скорость не постарадает, по-моему самое правильное решение.

Да, верно ведь. :)