原型如下：
#include <unistd.h>
ssize_t read (int __fd, void *__buf, size_t __nbytes);
如果是读【普通文件】，可能的返回是：
- 0读到了文件尾。
- <= nbytes，可能是文件没有这么多字节了。
- -1，出错。
注意，-1出错的时候，errno会返回错误码。
其中有一个errno需要引起我们注意，就是EINTR。手册里面是这么解释的：当任何数据没有读到的时候，如果调用被中断，返回-1且errno设置为EINTR。言外之意是如果读到了，会返回读了多少，这种有数据的不会返回-1。
看起来这个异常情况需要处理，避免真的不凑巧刚调用，被信号中断了，那其不是被误认为出错了吗？可是真的是这种情况要处理吗？
还真有人说需要处理（见https://blog.csdn.net/feit2417/article/details/82498653），他文章里面是这么说的：
分享一个工业级代码，read读文件数据。
读的过程中，调用被信号中断,于是返回一个EINTR错误，read读取失败。
由于没有读到数据而被意外中断，所以需要从新读数据。while (ret < 0 && EINTR == errno);
实例代码：
bzero(buf, sizeof(buf));
do {
ret = read(0, buf, sizeof(buf) - 1);
} while(ret < 0 && EINTR == errno);
if (ret < 0) {
perror ("read");
continue;
}
上面的代码看着很严谨，确实是读文件的时候考虑的更全面，避免了EINTR的极端情况。
实际上需要这么做吗
？
为了回答这个问题，我们man 7 signal，可以看到对信号的详细说明，其中有一段对系统调用（或库调用）如何被中断的描述：
在慢速设备上调用read/write/ioctl时候(slow system call)，如果调用被中断的时候，已经传了一些数据，
将会返回成功的数据量。注意：本地磁盘不是慢速设备，磁盘设备上的IO操作不会被信号中断。
从这段描述，我们可以知道，如果是针对本地磁盘文件的read操作，因为不会被中断，所以无需处理返回-1，且errno为EINTR的情况。上述代码针对本地文件是无任何增强的。但是如果是socket，terminal，pipe上进行读数据操作的时候，因为是慢速设备，是可能被中断的。在这种慢速设备场景下，如果被中断，且当时还没有读取到任何数据，虽然上述说明中没具体说，但是言外之意是会返回-1，同时errno为EINTR。所以这种情况下，需要重启读取操作。
结论
如果确认是读本地磁盘文件，代码无需处理这类情况，简洁的实现如下：
ret = read(0, buf, cnt);
if (ret < 0) {
perror ("read");
}
... deal the data in buf
如果是读取的是socket，pipe，terminal等设备数据时候，需要封装一个函数，处理中断以及重新启动读取操作，直到读满我们期望的数据：
int new_read(int fd, char *buf, int count) {
int left_bytes = count;
int read_bytes;
char *pos = (char *)buf;
while (left_bytes > 0) {
read_bytes = read(fd, pos, left_bytes);
if (read_bytes < 0) {
if (errno == EINTR) {
continue; /* Restart the IO operation again. */
} else {
return -1;
}
} else if (read_bytes == 0) {
return (count - left_bytes);
}
left_bytes -= read_bytes;
pos += read_bytes;
}
}
APUE对这个情况也有进一步的说明：
对于如何处理read/write部分数据已经处理（读/写）的调用，早期的系统两种可选择：
1）可以报失败及EINTR；
2）返回成功的数量；
历史上，从System V派生的系统会将这种调用处理为失败，而BSD派生的系统会成功返回（返回部分数据数量）。
POSIX.1标准的2001版采用了BSD风格的语义。