On 08/07/2017 03:57 AM, Vladimir Sementsov-Ogievskiy wrote: > 07.08.2017 11:23, Daniel P. Berrange wrote: >> On Fri, Aug 04, 2017 at 06:14:27PM +0300, Vladimir Sementsov-Ogievskiy >> wrote: >>> Fix nbd_send_request to return int, as it returns a return value >>> of nbd_write (which is int), and the only user of nbd_send_request's >>> return value (nbd_co_send_request) consider it as int too. >> The real problem here is the return value of nbd_write() - it should be >> a ssize_t, not an int, since it is propagating the return value of >> nbd_rwv() which is ssize_t. > > It was changed in f5d406fe86bb (sent in May) > The discussion actually was started half a year ago: > https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00825.html > > >> Basically all functions that do I/O and >> return the number of bytes read/written should be ssize_t - any use of >> int is a bug.
If returning the size matters, then yes, not using ssize_t is a bug. But if all we need is to know whether an entire expected length was read (and treat ANY partial read the same as failure), then a mere int becomes enough to encode the results. Where I'm less certain is whether this change in semantics simplifies later patches, or loses information that might have been useful. But intuitively, ANY encounter of EOF means that NBD needs to quit trying to talk to the other end of the socket, whether or not the EOF occurred on a nice message boundary; and the rest of the protocol is strongly tied to messages, where we don't act until we have read the entire expected message; so if a later patch is indeed simpler by not returning bytes read, this patch might be okay. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature