send() всегда возвращает либо -1, либо указанный размер буфера

Если это не обещано четко, рассчитывать на это не следует. Тем более, что:

With zero flags argument, send() isequivalent to write(2)

да, эта ремарка несколько неприятна. Однако в самом описании send() четко говорится, что если места нет и не будет, то -1, иначе блокируемся да посылки.

Просто иначе получается, что корректный send всегда должен быть в цикле со сдвигом указателя посылки. Правда, корректный send всегда должен быть в цикле и так из-за EINTR...

Ну и возможную причину partail send в описании send() я найти не могу (

Учитывая величины цифр, есть соблазн трактовать сей опыт хочется трактовать как кривую реализацию стандартов posix при фантастических length.

memcpy

Для чего тебе это надо? Если для развития кругозора - то да, стоит поразмыслить и сделать выводы. Но если экономии трех букв в коде, типа «так быстрее, потому-что я знаю как работает ф-я», то настоятельно рекомендую ознакомиться с притчей о старике по имени adobe, и его слуге по имени memcpy. Очень поучительная история.

Просто по здравому смыслу, stream-oriented протоколы имеют право выполнять partial write.

Это конечно так. Однако, send ничего про это не говорит )

Историю знаю, но там они явно нарушили явное требование. Хочу знать, что сказать детям. Видимо, «блокирующий send всегда надо оборачивать циклом, для верности» (или как минимум при объеме данных более килобайта).

Если честно, я вообще то не совсем понимаю, что именно у тебя вызвало сомнения. В man page ясно написано:

On success, these calls return the number of characters sent. On error, -1 is returned, and errno is set appropriately.

так что в любом случае правильный (принципиальный) код будет такой:

int bytes_sent = 0;
int ret;
while (bytes_sent < buff_len) {
   ret = send(buffer+bytes_sent, buff_len-bytes_sent);
   if (ret < 0) {
       return ret;
   }
   bytes_sent += ret;
}

В man page её и не будет. Это требование стандарта. Технически причина в том, что внутренних буферов ярда для пакетов может не хватать. При правильно написанном модуле может быть банальная нехватка памяти например. Тысячи причин могут быть. Стандарт это не оговаривает и не может оговорить, т.к. это уже детали реализации.

так что в любом случае правильный (принципиальный) код будет такой

Э, а вышеупомянутый errno=EINTR? Хотелось бы дать send'у в этом случае ещё шанс.

Да и bytes_sent должно быть типа size_t, как и buff_len

size_t bytes_sent = 0;
int ret;
while (bytes_sent < buff_len) {
   ret = send(buffer+bytes_sent, buff_len-bytes_sent);
   if (ret < 0 && errno != EINTR) {
       return ret;
   }
   else if (ret > 0) {
      bytes_sent += ret;
   }
}

Я так и написал, а потом задувмался, не слишком ли я все усложняю....

Да, кстати, надо же еще проверять EINTR при возврате -1 как особый случай, это не повод же бросать попытки )

Учи детей писать правильный код изначально, не ломай им мозги.

Мне кажется тут " и" вместое ", не" скорее

Уверен, что и тут можно ещё найти, к чему прицепиться.

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

Не внимательно читаешь. Я специально в скобочках написал слово «принципиальный». А этот кусок кода даже не откомпилируется, да.

Причём -1 и EINTR будет только в случае, когда совсем не было переданно данных, иначе и возвращается количество фактически переданных байт на момент получения сигнала. Это в случае с stream-протоколами.

И если удалённая сторона закроет tcp-сокет, то тоже будет возвращено кол-во переданных байт, и только следующий send() вернёт -1 и ошибку сокета.