Thread: sendto() Failing: errno = EINVAL on Linux, errno = 0 on SunOS

Originally Posted by brewbuck

Also, the sendto() most decidedly does NOT require that you keep the buffer around until some indeterminable point in the future. After sendto() has returned, the data is safely in some buffer somewhere for transmission.

Brewbuck... that's what I thought too... but not so.

Your data pointer and sockaddr pointers do have to be maintained until the data is actually sent.

See my thread in the networking forum, where I tripped over exactly this issue. My data buffer, being composed in global memory was safe enough but the sockaddr at the pointer passed into the function was being deleted by a garbage collector.

My messages were not being sent because I naively thought sendto() would not return until the data was either safely buffered or actually sent, so I went on to houseclean the memory right after sending. The messages ended up not being sent...

I trapped the exact condition by commenting out the code releasing the memory and suddenly messages were being sent. Reactivate the code... no send. Comment it out... sent. And... no error messages. sendto was satisfied it's job was done... even though the operation failed.

I'm guessing this isn't a well known problem because it would be fairly rare that someone would send a datagram and microseconds later delete the sockaddr. I'm guessing the general practice would be more like the rest of my project... the sockaddr is a variable that sits in memory until re-used, so it remains valid until the next call to sendto().

You might say "the operation was a complete success but the patient died anyway."

Originally Posted by brewbuck

True, but no function will ever set errno to 0. The only way errno is 0 is if it was 0 before the call already and the function did not set it.

All right! I did not know that...I love it when I learn something new