Я указатель гольца & использовал таНос какC++ размера указатель гольца превышает после таНоса
char *message;
message=(char *)malloc(4000*sizeof(char));
позже я получаю данные из сокета в сообщении, что происходит, если данные превышает 4000 байт?
Я предполагаю, что вы спрашиваете, что произойдет, если вы делаете что-то вроде этого:
recv(socket,message,5000,0);
и количество считанных данных больше, чем 4000.
Это будет определено поведение, так вам нужно убедиться, что этого не произойдет. Всякий раз, когда вы читаете сокет, вы должны указывать максимальное количество символов для чтения.
Что было бы неопределенным поведением? Нет ничего плохого в получении сообщения, которое будет больше, чем некоторый буфер. –
@DavidSchwartz - Просто догадаться, в таком случае нам придется делать многократное чтение в сокете, пока вам нечего читать. Я прав. ? –
@ a4anurag Это может быть правдой для потоковых протоколов, таких как TCP. Это определенно неверно для протоколов дейтаграмм, таких как UDP. Но это не тот вопрос, который задал вопрос. –
Ваш вопрос не содержит много сведений о сетевом протоколе, см. Ответ от @DavidSchwartz.
Но сосредоточившись на буфере, в котором вы его храните: если вы попытаетесь записать больше чем 4K символов в память, выделенную message, ваша программа может потерпеть крах.
Если тест на размер сообщения, которое получено, вы могли бы сделать realloc:
int buf_len = 4000;
char *message;
message = static_cast<char*>(malloc(buf_len));
/* read message, and after you have read 4000 chars, do */
buf_len *= 2;
message = static_cast<char*>(realloc(message, buf_len));
/* rinse and repeat if buffer is still too small */
free(message); // don't forget to clean-up
Но это очень трудоемкий. Просто используйте a std::string
int buf_len = 4000;
std::string message;
message.reserve(buf_len); // allocate 4K to save on repeated allocations
/* read message, std::string will automatically expand, no worries! */
// destructor will automatically clean-up!
@DavidSchwartz Если он попытается записать более 4K в сообщение, у него будет нарушение памяти, не так ли? – TemplateRex
Вопрос, который он задал, - это то, что произойдет, если он получит большое сообщение. Если, например, он говорит о TCP, ни один из ваших ответов не имеет никакого смысла. –
@DavidSchwartz Я уверен, что вы правы, что это зависит от сетевого протокола. Но единственный приведенный код - это буфер 'char' фиксированного размера, и что произойдет, если будет получено больше данных. Это может быть stdin, который производит эти данные. Я интерпретировал вопрос как о том, как обращаться с проблемами памяти при попытке сохранить его в 'message' – TemplateRex
Это зависит от нескольких факторов. Предполагая, что в вашем коде нет ошибок, это будет зависеть от используемого вами протокола.
Если TCP, вы никогда не получите больше байтов, чем вы просили. Вы получите больше данных при следующем вызове функции приема.
Если UDP, вы можете получить усечение, вы можете получить сообщение об ошибке (например, MSG_TRUNC). Это зависит от особенностей вашей платформы и от того, как вы вызываете функцию приема. Я не знаю ни одной платформы, которая сохранит часть дейтаграммы для последующего вызова функции приема.
Конечно, если в вашем коде есть ошибка, и вы фактически переполняете буфер, могут произойти очень плохие вещи. Поэтому убедитесь, что вы передаете только нормальные значения для любой функции приема, которую вы используете.
Для лучшего результата, вы получите сообщение об ошибке ошибки сегментации
Могу ли я спросить, почему вы используете 'malloc' в C++? Кроме того, 'sizeof (char)' указывается всегда как '1'. –
что у меня есть альтернативный вариант, я должен использовать его как char * message = new char [4000]; – user3559050
Да, именно это. –