0

Does it have to? I've always been fuzzy on this sort of stuff, but if I have something like:

char buf[256];
read(fd, buf, 256);

write(fd2, buf, 256);

Is there potential for error here, other than the cases where those functions return -1?

If it were to only read 40 characters, would it put a \0 after it? (And would write recognize that \0 and stop? Also, if it were to read 256 characters, is there a \0 after those 256?

alk
  • 69,737
  • 10
  • 105
  • 255
user3475234
  • 1,503
  • 3
  • 22
  • 40
  • No. `read(2)` doesn't add zero terminator even if it could only read less than the requested number of bytes. – P.P Jun 10 '15 at 14:04
  • 2
    When you have such kind of doubts, the fastest and most reliable way to understand the answer is to just read the documentation. There are online sources, there are man pages, etc. – Kiril Kirov Jun 10 '15 at 14:05
  • As far as I can tell, the standard makes no comment on the contents of buf other than the data that is actually read. Maybe we need a [language-lawyer]. It would be very unusual for it to put anything there, though. – Random832 Jun 10 '15 at 14:09
  • @alk What is not documented is undefined. – Random832 Jun 10 '15 at 14:15
  • @Random832: Sorry I deleted the comment you are referring to. I moved it to my answer. – alk Jun 10 '15 at 14:37
  • 1
    You need to use the return value of `read` ... `bytesread = read(fd, buf, 256); write(fd, buf, bytesread);` – pmg Jun 10 '15 at 15:12

4 Answers4

8

No.

Consider reading binary data (eg. a photo from a file): adding extra bytes would corrupt the data.

Richard
  • 106,783
  • 21
  • 203
  • 265
8

does read() add a '\0'?

No, it doesn't. It just reads.

From read()'s documentation:

The read() function shall attempt to read nbyte bytes from the file associated with the open file descriptor, fildes, into the buffer pointed to by buf.


Is there potential for error here, other than the cases where those functions return -1?

read() might return 0 indicating end-of-file.

If reading (also from a socket descriptor) read() not necessarily reads as much bytes as it was told to do. So in this context do not just test the outcome of read against -1, but also compare it against the number of bytes the function was told to read.


A general note:

Functions do what is documented (at least for proper implementations of the C language). Both your assumptions (autonomously set a 0-termination, detect the latter) are not documented.

alk
  • 69,737
  • 10
  • 105
  • 255
  • `read()` may also return a value between 0 and 256 even when `fd` is something other than a socket descriptor. Checking for a short read should be done for any `read()`. – Michael Burr Jun 10 '15 at 15:19
1

From the man page:

Synopsis

#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);

That is void *, not char *, because read() reads bytes, not characters. It reads zero bytes as well as any other value, and since blocks of bytes (as opposed to strings) aren't terminated, read() doesn't.

DevSolar
  • 67,862
  • 21
  • 134
  • 209
0

Does it have to?

Not unless the data that is successfully read from the file contains a '\0'...

Is there potential for error here, other than the cases where those functions return -1?

Yes. read returns the actual number of bytes read (or a negative value to indicate failure). If you choose to write more than that number of bytes into your other file, then you are writing potential garbage.

autistic
  • 1
  • 3
  • 35
  • 80