Raymond, David writes:
> I am confused about SSIZE_MAX and read(2)/write(2). The POSIX
> SSIZE_MAX is something like 2^15 -1. This seems to be a real
> limitation when writing to a TCP/IP socket, as I learned from
> experience. However, much larger reads and writes seem to be possible
> to files and UNIX sockets (pipes). This makes me uneasy, given the
> warning in the man pages for read(2)/write(2).
>
> Any insight on this topic would be appreciated.
I would guess this is part of the reason why ssize_t was invented
- so that half of the numeric range could be wasted in order for a
function to be able to return -1, and/or ridiculous notions of
symmetry.
Looking in /usr/src/sys/lib/libsa/read.c shows that different types
of file descriptor get their own read implementation (f->f_ops->read)
which I'm not awake enough to track down.
read(2) states:
... The system
guarantees to read the number of bytes requested if the descriptor
references a normal file that has that many bytes left before the end-of-
file, but in no other case.
Which suggests to me that the implementations for files and network
sockets are quite different and that, unsurprisingly, the version
for files is able to make a lot of assumptions and shortcuts that
the networking code path cannot.
Note that the manual also includes in the list of potential errors:
[EINVAL] nbytes was larger than SSIZE_MAX.
which is totally unqualified - ie. nbytes should not be larger than
SSIZE_MAX in *any* case. Also nbytes is a size_t while the function's
return value is ssize_t.
This all comes to you pre-coffee. Take it as you will.
Matthew
