Read/write exactly N bytes from/to file descriptor with C on Unix

Question

I know that read/write C functions from <unistd.h> are not guaranteed to read/write exactly N bytes as requested by size_t nbyte argument (especially for sockets).

How to read/write full buffer from/to a file(or socket) descriptor?

Answer 1

That read() and write() do not guarantee to transfer the full number of bytes requested is a feature, not a shortcoming. If that feature gets in your way in a particular application then it is probably better to use the the existing facilities of the standard library to deal with it than to roll your own (though I certainly have rolled my own from time to time).

Specifically, if you have a file descriptor on which you want to always transfer exact numbers of bytes then you should consider using fdopen() to wrap it in a stream and then performing I/O with fread() and fwrite(). You might also use setvbuf() to avoid having an intermediary buffer. As a possible bonus, you can then also use other stream functions with that, such as fgets() and fprintf().

Example:

int my_fd = open_some_resource();
// if (my_fd < 0) ...
FILE *my_file = fdopen(my_fd, "r+b");
// if (my_file == NULL) ...
int rval = setvbuf(my_file, NULL, _IONBF, 0);
// if (rval != 0) ...

Note that it is probably best to thereafter use only the stream, not the underlying file descriptor, and that is the main drawback of this approach. On the other hand, you can probably allow the FD to be lost, because closing the stream will also close the underlying FD.

Nothing particularly special is required to make fread() and fwrite() to transfer full-buffer units (or fail):

char buffer[BUF_SIZE];
size_t blocks = fread(buffer, BUF_SIZE, 1, my_file);
// if (blocks != 1) ...

// ...

blocks = fwrite(buffer, BUF_SIZE, 1, my_file);
// if (blocks != 1) ...

Do note that you must get the order of the second and third arguments right, however. The second is the transfer unit size, and the third is the number of units to transfer. Partial units will not be transferred unless an error or end-of-file occurs. Specifying the transfer unit as the full number of bytes you want to transfer and asking (therefore) for exactly one unit is what achieves the semantics you ask about.

Answer 2

Both read and write on success return ssize_t containing amount of bytes read/written. You can use it to construct a loop:

A reliable read():

ssize_t readall(int fd, void *buff, size_t nbyte) {
    size_t nread = 0; size_t res = 0;
    while (nread < nbyte) {
        res = read(fd, buff+nread, nbyte-nread);
        if (res == 0) break;
        if (res == -1) return -1;
        nread += res;
    }
    return nread;
}

A reliable write() (almost same):

ssize_t writeall(int fd, void *buff, size_t nbyte) {
    size_t nwrote = 0; size_t res = 0;
    while (nwrote < nbyte) {
        res = write(fd, buff+nwrote, nbyte-nwrote);
        if (res == 0) break;
        if (res == -1) return -1;
        nwrote += res;
    }
    return nwrote;
}

Basically it reads/writes until total amount of bytes != nbyte.

---

Please note, this answer uses only <unistd.h> functions, assuming there is a reason to use it. If you can use <stdio.h> too, see answer by John Bollinger, which uses fdopen;setvbuf and then fread/fwrite. Also, take a look at answer by Blabbo is Verbose for read_range function with a lot of features.

Answer 3

You use a loop.

For example, with proper error checking:

/** Read a specific number of bytes from a file or socket descriptor
 * @param fd        Descriptor
 * @param dst       Buffer to read data into
 * @param minbytes  Minimum number of bytes to read
 * @param maxbytes  Maximum number of bytes to read
 * @return          Exact number of bytes read.
 * errno is always set by this call.
 * It will be set to zero if an acceptable number of bytes was read.
 * If there was 
  and to nonzero otherwise.
 *                  If there was not enough data to read, errno == ENODATA.
*/
size_t  read_range(const int fd, void *const dst, const size_t minbytes, const size_t maxbytes)
{
    if (fd == -1) {
        errno = EBADF;
        return 0;
    } else
    if (!dst || minbytes > maxbytes) {
        errno = EINVAL;
        return 0;
    }

    char       *buf = (char *)dst;
    char *const end = (char *)dst + minbytes;
    char *const lim = (char *)dst + maxbytes;

    while (buf < end) {
        ssize_t n = read(fd, buf, (size_t)(lim - buf));
        if (n > 0) {
            buf += n;
        } else
        if (n == 0) {
            /* Premature end of input */
            errno = ENODATA;  /* Example only; use what you deem best */
            return (size_t)(buf - (char *)dst);
        } else
        if (n != -1) {
            /* C library or kernel bug */
            errno = EIO;
            return (size_t)(buf - (char *)dst);
        } else {
            /* Error, interrupted by signal delivery, or nonblocking I/O would block. */
            return (size_t)(buf - (char *)dst);
        }
    }

    /* At least minbytes, up to maxbytes received. */
    errno = 0;
    return (size_t)(buf - (char *)dst);
}

Some do find it odd that it clears errno to zero on successful calls, but it is perfectly acceptable in both standard and POSIX C.

Here, it means that typical use cases are simple and robust. For example,

    struct message  msgs[MAX_MSGS];

    size_t  bytes = read_range(fd, msgs, sizeof msgs[0], sizeof msgs);
    if (errno) {
        /* Oops, things did not go as we expected.  Deal with it.
           If bytes > 0, we do have that many bytes in msgs[].
        */
    } else {
        /* We have bytes bytes in msgs.
           bytes >= sizeof msgs[0] and bytes <= sizeof msgs.
        */
    }

---

If you have a pattern where you have fixed or variable sized messages, and a function that consumes them one by one, do not assume that the best option is to try and read exactly one message at a time, because it is not.

This is also why the above example has minbytes and maxbytes instead of a single exactly_this_many_bytes parameter.

A much better pattern is to have a larger buffer, where you memmove() the data only when you have to (because you're running out of room, or because the next message is not sufficiently aligned).

For example, let's say you have a stream socket or file descriptor, where each incoming message consists of a three byte header: the first byte identifies the message type, and the next two bytes (say, less significant byte first) identify the number of data payload bytes associated with the message. This means that the maximum total length of a message is 1+2+65535 = 65538 bytes.

For efficiently receiving the messages, you'll use a dynamically allocated buffer. The buffer size is a software engineering question, and other than that it has to be at least 65538 bytes, its size – and even whether it should grow and shrink dynamically – depends on the situation. So, we'll just assume that we have unsigned char *data; pointing to a buffer of size size_t size; already allocated.

The loop itself could look something like the following:

    size_t  head = 0;  /* Offset to current message */
    size_t  tail = 0;  /* Offset to first unused byte in buffer */
    size_t  mlen = 0;  /* Total length of the current message; 0 is "unknown"*/

    while (1) {

        /* Message processing loop. */
        while (head + 3 <= tail) {

            /* Verify we know the total length of the message
               that starts at offset head. */
            if (!mlen)
                mlen = 3 + (size_t)(data[head + 1])
                         + (size_t)(data[head + 2]) << 8;

            /* If that message is not yet complete, we cannot process it. */
            if (head + mlen > tail)
                break;

            /*             type        datalen,  pointer to data */
            handle_message(data[head], mlen - 3, data + head + 3);

            /* Skip message in buffer. */
            head += mlen;

            /* Since we do not know the length of the next message,
               or rather, the current message starting at head,
               we do need to reset mlen to "unknown", 0. */
            mlen  = 0;
        }

        /* At this point, the buffer contains less than one full message.
           Whether it is better to always move a partial leftover message
           to the beginning of the buffer, or only do so if the buffer
           is full, depends on the workload and buffer size.
           The following one may look complex, but it is actually simple.
           If the current start of the buffer is past the halfway mark,
           or there is no more room at the end of the buffer, we do the move.
           Only if the current message starts in the initial half, and
           when there is room at the end of the buffer, we leave it be.
           But first: If we have no data in the buffer, it is always best
           to start filling it from the beginning.
        */
        if (head >= tail) {
            head = 0;
            tail = 0;
        } else
        if (head >= size/2 || tail >= size) {
            memmove(data, data + head, tail - head);
            tail -= head;
            head = 0;
        }

        /* We do not have a complete message, but there
           is room in the buffer (assuming size >= 65538),
           we need to now read more data into the buffer. */
        ssize_t  n = read(sourcefd, data + tail, size - tail);
        if (n > 0) {
            tail += n;

            /* Check if it completed one or more messages. */
            continue;

        } else
        if (n == 0) {
            /* End of input.  If buffer is empty, that's okay. */
            if (head >= tail)
                break;

            /* Ouch: We have partial message in the buffer,
                     but there will be no more incoming data! */
            ISSUE_WARNING("Discarding %zu byte partial message due to end of input.\n", tail - head);
            break;

        } else
        if (n != -1) {
            /* This should not happen.  If it does, it is a C library
               or kernel bug.  We treat it as fatal. */
            ISSUE_ERROR("read() returned %zd; dropping connection.\n", n);
            break;

        } else
        if (errno != EINTR) {
            /* Everything except EINTR indicates an error to us; we do
               assume that sourcefd is blocking (not nonblocking). */
            ISSUE_ERROR("read() failed with errno %d (%s); dropping connection.\n", errno, strerror(errno));
            break;
        }

        /* The case n == -1, errno == EINTR usually occurs when a signal
           was delivered to a handler using this thread, and that handler
           was installed without SA_RESTART.  Depending on what kind of
           a device or socket sourcefd is, there could be additional cases;
           but in general, it just means "something unrelated happened,
           but you were to be notified about it, so EINTR you get".
           Simply put, EINTR is not really an error, just like
           EWOULDBLOCK/EAGAIN is not an error for nonblocking descriptors,
           they're just easiest to treat as an "error-like situation" in C.
        */
    }

    /* close(sourcefd); */

Note how the loop does not actually try to read any specific amount of data? It just reads as much as it can, and processes it as it goes.

Could one read such messages precisely, by first reading exactly the three-byte header, then exactly the data payload? Sure, but that means you make an awful amount of syscalls; at minimum two per message. If the messages are common, you probably do not want to do that because of the syscall overhead.

Could one use the available buffer more carefully, and remove the type and data payload length from the next message in the buffer as soon as possible? Well, that is the sort of question one should discuss with colleagues or developers having written such code before. There are positives (mainly, you save three bytes), and negatives (added code complexity, which always makes code harder to maintain long term, and risks introducing bugs). On a microcontroller with just 128 bytes of buffer for incoming command messages, I probably would do that; but not on a desktop or server that prefers a few hundred kilobytes to a couple of megabytes of buffer for such code (since the memory "waste" is often covered by the smaller number of syscalls especially when processing lots of messages). No quick answers! :)-