send(2) takes a buffer and a buffer length. It can return either an error, or some number of bytes successfully sent up to the size of the buffer length. In some cases, send will send fewer than the number of bytes requested (e.g. https://stackoverflow.com/a/2618755/939259).
Is there a way to consistently trigger a short send in a unit test, other than sending a big message and firing a signal from another thread and hoping to get lucky?
Just roll your own:
#include <sys/types.h>
#include <sys/socket.h>
ssize_t mysend(int fd, void * buff, size_t len, int flags)
{
#if WANT_PARTIAL_SEND
len = 1 + urand(len -1);
#endif
return send(fd, buff, len, flags);
}
If you pack the code-to-be tested into a shared library (or a static library with the symbols weakened), then your testing executable (which links with the library) will be able to override send for both itself and the libraries it links.
Example (overrides write rather than send):
#!/bin/sh -eu
cat > code.c <<EOF
#include <unistd.h>
#include <stdio.h>
ssize_t hw(void)
{
static const char b[]="hello world\n";
return write(1, b, sizeof(b)-1);
}
void libfunc(void)
{
puts(__func__);
hw();
}
EOF
cat > test.c <<'EOF'
#include <stdio.h>
void libfunc(void);
ssize_t hw(void);
#if TEST
ssize_t hw(void)
{
puts("override");
return 42;
}
#endif
int main()
{
libfunc();
puts("====");
printf("%zu\n", hw());
}
EOF
gcc code.c -fpic -shared -o libcode.so
gcc test.c $PWD/libcode.so -o real
gcc -DTEST test.c $PWD/libcode.so -o mocked
set -x
./real
./mocked
Example output:
hello world
hello world
libfunc
====
12
libfunc
override
====
override
42
This overshadows the libc implementation of the symbol and while there are mechanism for accessing the overridee (namely dlopen and/or -Wl,--wrap), you shouldn't need to access it in a unit test (if you do need it in other unit tests, it's simplest to just put those other unit tests in a different program).
send(2) by default returns only when all data was successfully copied to the send buffers.
The possible ways to force it to send less bytes highly depend on the circumstances.
If you
1. can access the socket
2. do not want to alter the behaviour of all calls to send in your linked binary,
then you could set the socket non-blocking. Then, a call to send will send as much octects as possible. The amount of octets sent depends mainly on the amount of free memory in the send buffer of the socket you want to send on.
Thus, if you got
uint8_t my_data[NUM_BYTES_TO_SEND] = {0}; /* We don't care what your buffer actually contains in this example ... */
size_t num_bytes = sizeof(my_data);
send(fd, my_data, num_bytes);
and want send to send less than num_bytes, you could try to decrease the send buffer of your socket fd .
Whether this is possible, how to accomplish this might depend on your OS.
Under Linux, you could try to shrink the send buffer by setting the buffer size manually by using setsockopt(2) via the option SO_SNDBUF, descibed in the man page `socket(7):
uint8_t my_data[NUM_BYTES_TO_SEND] = {0};
size_t num_bytes = sizeof(my_data);
size_t max_bytes_to_send = num_bytes - 1; /* Force to send at most 1 byte less than in our buffer */
/* Set the socket non-blocking - you should check status afterwards */
int status = fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_NONBLOCK);
/* reduce the size of the send buffer below the number of bytes you want to send */
setsockopt (fd, SOL_SOCKET, SO_SNDBUF, &max_bytes_to_send, sizeof (size_t));
...
send(fd, my_data, num_bytes);
/* Possibly restore the old socket state */
Possibly you also have to fiddle around with the option SO_SNDBUFFORCE .
Further info for
SO_SNDBUF etc: What are SO_SNDBUF and SO_RECVBUF Anyhow, the best way to go for you depends on the circumstance.
If you look for a reliable solution to check code you perhaps cannot even access, but link into your project dynamically, you might go with the other approach suggested here: Overshadow the send symbol in your compiled code .
On the other hand, this will impact all calls to send in your code (you could, of course bypass this problem e.g. by having your send replacement depend on some flags you could set).
If you can access the socket fd, and want only specific send calls to be impacted (as I guess is the case with you, since you talk about unit tests, and checking for sending less bytes than expected in all your tests is probably not what you want?), then going the way to shrink the send buffer could be the way to go.
