Incorrect status reporting from OS_SocketSendTo_Impl

[shuq0]

Describe the bug
The return value of sendto returns the number of characters sent on success and -1 on error. In OS_SocketSendTo_Impl the return of sendto is being assigned as os_status and returned. This results in a non-zero (OS_SUCCESS) status being reported back to the calling function which is interpreted as an error

To Reproduce
Steps to reproduce the behavior:

1. Put breakpoint on OS_SocketSendTo_Impl
2. Enable TO output using cmdUtil
3. Chaeck the value of os_result

Expected behavior
os_result should be OS_SUCCESS if the return value of sendto != buflen.

Code snips

osal/src/os/portable/os-impl-bsd-sockets.c

OS_SocketSendTo_Impl { ...

 os_result = sendto(impl->fd, buffer, buflen, MSG_DONTWAIT, sa, addrlen);
    if (os_result < 0)
    {
        OS_DEBUG("sendto: %s\n", strerror(errno));
        return OS_ERROR;
    }

    return os_result;
...

Reporter Info
Syed Huq, Kepler Communications.

[skliper]

Not really clear what makes the current behavior "incorrect". OS_SocketSendTo documents the current behavior:

osal/src/os/inc/osapi-sockets.h

Lines 386 to 403 in 88f72d7

	/**
	* @brief Sends data to a message-oriented (datagram) socket
	*
	* This sends data in a non-blocking mode. If the socket is not currently able to
	* queue the message, such as if its outbound buffer is full, then this returns
	* an error code.
	*
	* @param[in] sock_id The socket ID, which must be of the datagram type
	* @param[in] buffer Pointer to message data to send @nonnull
	* @param[in] buflen The length of the message data to send @nonzero
	* @param[in] RemoteAddr Buffer containing the remote network address to send to
	*
	* @return Count of actual bytes sent or error status, see @ref OSReturnCodes
	* @retval #OS_INVALID_POINTER if argument is NULL
	* @retval #OS_ERR_INVALID_SIZE if passed-in buflen is not valid
	* @retval #OS_ERR_INVALID_ID if the sock_id parameter is not valid
	* @retval #OS_ERR_INCORRECT_OBJ_TYPE if the handle is not a socket
	*/

This results in a non-zero (OS_SUCCESS) status being reported back to the calling function which is interpreted as an error

The API is documented as returning actual bytes sent, so the calling function should handle positive return values.

[shuq0]

Thanks for the clarification, fixed the calling function to account for this case.